ACDL研发流程01：认识ACDL以及为什么需要新的研发体系
ACDL研发流程系列第1篇，共15篇。
1.ACDL是什么
ACDL是Agent Collaborative Development Lifecycle的缩写，中文名称为“Agent协同研发体系”。它是当前项目根据自己的实际研发方式形成的一套方法，用来组织人和Agent从发现问题、设计、实施、验证到正式版本的协作过程。
它不是行业标准，也不是某一种Agent编程工具的使用方法。ACDL关注的核心问题是：当Agent已经能够实际读取仓库、修改跨模块代码、运行测试、操作环境并参与评审时，项目怎样仍然保持清楚的方向、边界和结果。
ACDL也不等于“让Agent写代码”。编码只是其中一个环节。
2.为什么Agent参与以后需要重新组织研发过程
Agent带来的最大变化，不只是写代码更快，而是很多原来需要多人分别完成的工作，可以由一个Agent连续跨越多个层次完成。
这会带来明显效率，也放大几类风险：
- 一个模糊想法可以很快被实现成复杂方案，即使方向一开始就错了；
- 对话里随口讨论的内容可能被下一次会话误当成已经确认的要求；
- 多个Agent可以同时修改不同模块，也可能同时依赖同一个尚未稳定的接口或数据结构；
- 代码、设计、测试和环境可能分别停留在不同状态；
- Agent很容易报告“测试通过”，但Director仍然不知道最初的问题是否真正解决；
- 一项修改进入
main以后，如果没有明确记录，很难再回答它最终属于哪个正式版本。
传统研发中的需求管理、领域建模、测试、CI和代码评审仍然有价值。ACDL没有要替代这些做法，而是重新回答四个问题：
1.项目上下文放在哪里；
2.什么事情Agent可以直接决定，什么事情需要Director确认；
3.多个Agent怎样安全地同时工作；
4.怎样判断一轮工作和一个正式版本真正结束。
3.ACDL已经怎样落在当前项目仓库里
ACDL不是一张独立流程图。它已经体现在仓库目录、编号、状态和工具中。
1 | project/ |
这些目录不是把同一件事重复写很多遍。
- 需求说明为什么要改变；
- 设计说明系统应该怎样工作；
- 实施记录说明这一轮实际做了什么；
- 环境记录说明现在运行什么；
- 版本记录说明最终正式交付了什么。
一个新Agent不需要依赖过去的聊天记忆来重新猜项目状态，只要沿这些入口读取当前任务所需的内容。
4.Agent进入仓库后从哪里开始
当前项目中的Agent先读取根目录AGENTS.md。它负责说明工作规则和安全边界，例如：
- 项目和文档从哪里进入；
- 哪些决定需要Director确认；
- 历史代码、真实数据和Secret怎样处理；
- 测试、发布和远程操作有哪些前置条件；
- 修改真实环境时哪些动作需要额外授权。
然后从docs/README.md进入当前项目记录，再按任务选择REQ、已经确认的设计、Loop记录、环境状态以及真正相关的代码和测试。
1 | AGENTS.md |
历史文档可以用来理解为什么曾经那样做，但不能因为搜索结果先出现一份旧材料，就拿它替代当前设计。
5.规范负责定规则，入口负责带路
docs/00-规范/保存需要长期重复执行的规则。Agent不必一开始把所有规范都读完，而是先从docs/00-规范/README.md判断当前任务涉及什么，再读取真正命中的章节。例如，改中文文档时看写作规范，判断是否要改设计时看设计评审规范，开展ACL、DFL或ERL时看实施流程规范。
规范告诉参与者怎样工作，不会替具体任务给出产品答案。某项功能当前应该怎样表现，仍然要从REQ和Accepted设计中读取；某次实施做了什么，则从对应Loop记录和实际代码中核对。手册只能帮助理解这些关系，不能成为另一套规则来源。
6.scripts把一部分规则变成可执行检查
仓库中的scripts/大致分成：
1 | scripts/ |
常用公开入口包括：
pnpm docs:check：检查文档结构、状态、编号、链接和追踪关系；pnpm verify：根据实际差异选择验证深度；pnpm trace:render：重新生成设计要求追踪视图；pnpm issue:new：登记需要持续追踪的问题；pnpm loop:new：创建ACL编号和记录骨架；pnpm loop:status：按允许的状态变化更新Loop；scripts/operations/：安装、升级、回退、恢复和开发环境发布。
运行脚本前仍然要理解它会读取什么、修改什么。verify/主要是检查；workflows/会改仓库记录；operations/会真正改变环境，三者风险完全不同。
7.一项产品变化怎样穿过这些目录
继续用“收藏会话”这个教学例子：
1 | docs/01-需求/ |
这条路线可以返回前面。实现发现设计无法落地，就回到设计；真实使用发现需求本身需要改变，就回到REQ；独立评审发现实现缺陷，则登记问题并开始新的处理。
目录的作用是让事情有明确归属，不是强迫每项工作只能单向前进。
8.ACDL中的Director和Agent
Director
Director是对方向、取舍、授权和最终结果负责的人，不是传统公司岗位名称。
在不同阶段，他可能在做完全不同的判断：
- 发现问题时，从用户角度判断痛点是否真实；
- 需求阶段决定是否改变产品；
- 设计阶段确认用户行为、架构、安全和数据取舍；
- 实施阶段处理超出Agent边界的决定；
- DFL中真实使用产品；
- 版本阶段确认实际范围和剩余风险。
这些工作不要求Director亲手写完所有代码或执行每条测试，但最终的产品决定、风险接受和交付结论不能交给Agent自行批准。
Agent
Agent是实际研发参与者，而不只是代码生成器。它可以：
- 调查问题和现有实现；
- 参与需求和设计讨论；
- 修改前端、后端、数据、测试和部署；
- 运行自动化和实机验证；
- 收集失败证据并定位原因；
- 作为独立评审者检查其它工作。
Agent能力越强，边界越要清楚。它可以提出改变产品的建议，但不能因为方案看起来合理就自行把它实现成新的产品规则。
9.项目上下文不能只存在聊天里
一个长期项目会经历大量会话和不同Agent，也可能同时存在多个工作目录。某次聊天里的信息不会自动成为其它会话都知道的共同背景。
因此，重要的需求和决定要进入项目文档；当前工作范围要进入Loop启动方案；实际失败和结果要进入实施记录；环境和版本状态也要有自己的长期入口。文档不再只是帮助人理解代码的说明材料，而要成为Director和Agent都能持续读取的项目源码。
这不是把“所有聊天都转成文档”，而是只把以后继续工作仍然需要知道的信息写到它负责的位置。
10.为什么按任务而不是按岗位组织Agent
Agent可以跨前端、后端、数据和测试完成端到端工作，因此当前项目更适合按可以独立完成和验证的结果拆任务，而不是把同一功能切成“前端Agent”“后端Agent”“测试Agent”。
一个任务如果必须等其它Agent完成才能证明自己正确，它往往只是一个实施步骤，而不是适合并行的独立任务。
ACDL后面的ACL和并行协作规则，就是为了让不同Agent在彼此清楚的任务边界内工作，而不是共享一个模糊现场。分支和worktree是需要隔离文件修改时的工具，不是每轮ACL必须补齐的形式。
11.代码合并和部署都不能自动代表完成
以下几件事必须区分：
- 代码已经写完；
- 自动化验证已经通过；
- 候选已经部署到环境；
- Director已经真实使用并确认体验；
- 独立工程评审已经结束；
- Loop已经完成；
- 正式版本已经验收并创建Git标签。
它们回答不同问题。某项工作可能只需要做到其中一部分，也可能根据风险需要继续更多检查。ACDL要求把“完成到哪一步”说准确，而不是用一个泛化的“已完成”覆盖所有状态。
12.ACDL最终想得到什么
ACDL不是为了增加流程对象，而是让下面这条协作能够长期重复：
1 | Director给出问题、方向和边界 |
13.与外部方法的关系
行业已经在尝试回答类似问题，但相似名称之下往往对应不同对象和范围。
例如，微软提出的Agent development lifecycle更关注怎样发现、实验、构建、部署和稳定运行一个Agent产品。ACDL面对的问题不同：不论最终产品是不是Agent，Director都在使用Agent参与软件研发，因此它关注的是人和Agent怎样共同管理需求、设计、实施、验证和版本。
GitHub的Spec Kit强调规格驱动开发，让规格成为Agent实施时的重要依据，而不是只把代码当成真相。这个方向对ACDL很有启发，但“规格到实现”仍然不等于一项产品变化已经完整交付。环境发布、真实使用、独立评审、未解决问题和正式版本仍然需要继续处理。
这些方法都在快速发展，对“Agent是产品、开发工具、工作者还是协作者”也没有完全统一的语义。ACDL会吸收其中适合当前项目的思想，但不会为了对齐某个外部方法而重新包装自己的研发对象和流程。
下一章会回到项目最早期，说明当只有一个模糊想法时，怎样先通过PoC和MVP建立项目骨架，而不是一开始就套上完整ACDL。