项目生命周期

无论实现由人类独立完成、AI 辅助完成，还是由多人和多个代理协作完成，都需要理解目标、控制范围、验证行为并明确交付责任。流程按项目职责和风险裁剪，与团队人数无关；阶段可以合并，关键决策和验收结果不能丢。AI 任务的具体边界和责任按 AI 参与开发工作流执行。

阶段	要回答的问题	输出或完成条件
探索	谁遇到什么问题，为什么值得做？	明确用户、价值、证据、未知项和是否继续。
定义	做什么、不做什么，怎样判断成功？	范围、需求、验收条件、非功能约束、数据与权限边界。
设计	哪些组件和仓库会变化，契约如何兼容？	需要时的架构图、接口/数据方案、风险、备选方案和 ADR。
计划	哪些小步可委派给人或 AI 并独立检查？	有顺序的切片、依赖、每项任务的范围、责任人、验证、发布和恢复安排。
实现	人或 AI 是否沿获准边界解决了目标问题？	代码、配置、迁移、测试和受影响文档同步更新；不扩大权限或假定未定决策。
评审	行为、风险与证据是否可供人类责任人判断？	聚焦的 PR、实际检查结果、兼容性和未解决问题；AI 不独自批准自己的改动。
发布	要发布哪个版本或构建物，目标环境是什么？	可追溯工件、变更说明、发布验收和回退/前向恢复路径。
运维与维护	怎样发现故障、修复、升级和控制成本？	责任人、配置、监控、支持流程和依赖维护。
退役	消费者、数据、域名和凭据如何处理？	通知和迁移、数据处置、停止服务、撤销权限和保留记录。

需求与验收

较大的工作先写简短项目说明或计划：问题、用户、预期价值、范围和非目标；用户旅程或系统行为；可观察的验收条件；性能、可用性、隐私、成本、兼容和恢复约束；受影响仓库、组件、数据和外部服务。未确认项标记为“假设”或“待决”，写明由谁和何时决定。

验收条件描述观察到的结果，不以“代码已写”代替。例如，写“撤销权限后旧会话不能访问受保护资源，并有负向测试”，不要只写“完成权限模块”。

说明当前情况与目标情况的区别。重大或难以回滚的决定应保留背景、选项、决定和后果；采用 ADR 的项目将其按序放在 docs/adr/。计划应包含切片、跨仓库依赖、接口和迁移顺序、自动与人工验证、发布及恢复方式。

计划是尚未实现的设计，不是实现证据。只有实际运行的检查才可标为通过；图表应注明“当前（已核实）”“拟议”或“示例”。

先检查仓库说明、AGENTS、清单、源码、测试、CI、文档、配置和未提交状态。保留仍然清晰的现有布局、公开导入、接口、分支与本地数据。先增加权威文档和导航，再考虑重命名或移动；任何兼容性变化都要列出受影响消费者、迁移和回退步骤。

对非平凡工作记录：改动范围、决策和理由、实际执行的命令与结果、受影响文档、已接受的取舍、未解决风险以及下一步。文档更改不需要为了形式而添加应用测试；如果构建或链接检查没有运行，也应如实说明。