探索一个适配人类工作流的Agent

二月的第一个博客，在一个非常非常有意思的节点。截至今天，我让公司的产品们都安装上了 Claude Code，加上团队里的开发们，我们可以开始串整个开发流程了。

我针对的不是 Claude Code，而是 Agentic AI Tool。只不过截至此时此刻，Claude Code 提供的 best practice 最实用。

当产品团队也开始使用这个面向程序员的 Agentic AI Tool 时，大家开始解锁完全不一样的用法，很多事情变得清晰起来。如果产品团队不开始使用的话，我永远不会知道这样的诉求，毕竟大家的工作内容差别巨大。

我给大家的预设是，大家可以用这个 tool 进行数据分析，但是数据分析并非她们平时工作中占大头的工作，她们对此工具的第一个诉求是，帮忙读取当前的实现逻辑！对的，当一个产品运行了三年五年，没有人记得一开始的细节，当我要评估一个需求的影响时，我最希望知道的就是，它现在是怎么实现的？

当我给 Claude Code 配置产品代码库和持续更新代码的能力时，这个诉求自然而然就能够被攻克。

闲话说的有点多，回到开发流程的事情上。从我们最近对 AI 的能力探索来看，我们发现每个角色的边界正在发生变化。对于这个变化，我的看法是很悲观的，确切地说，开发人员的空间正在变小，产品人员的空间也在变小，同时双方衍生出了一些不一样的工作内容。

双方变小的空间，无疑都是被 agent 所挤压。当我越是了解 agent 能力，越是了解 LLM 的能力之后，对于将来工作的 workflow 中每个角色该做的事情，我就越是清晰。

今天我就想在这个博客里讨论，整个开发流程在 AI-driven 的时代，会是怎样的？

要开始这个话题，第一件事要理清楚的就是，我们有什么，我们拥有的东西有多大的能量？

我们拥有什么？

正如我在《回归文本》里谈到的那样，一个普通的软件公司，拥有的东西无非就是：

1. 数据
2. 文档
3. 代码

而现在的软件开发，介于 3-8 分的开发工作，无非就是在此基础上嵌入新的变化——需求变化。

需求变化可以很简单，比如将用户密码字段的校验规则由最长 32 字符改为 64 字符。

单单看到这样一句话，你是什么都做不了的，但是如果结合现有的代码和上下文（需求文档）来看，它（这一小句话）就能发挥很大的作用。基本上，需求八九不离十了，结合 brainstorm skill，把许多 uncertain 的部分确认之后，事情就能很顺利的进行下去。

换句话说，就连 LLM 幻觉的空间都没有了。

在这个例子和前提之下，我们继续进行探索。

流程上，发生变化的可能

从上面的这个例子来看，许多所谓的 task，都可以被 agent “包办”，至少从需求分析 -> 影响分析 -> 代码设计 -> 实现提交 PR 的整个过程。

所以我想象中的流程，就是，

1. [human being] 用户提出需求
2. [human being] PM 收集需求
3. [human being] PM 通过对话的形式与需求 agent 对话，完善需求，输出 PRD 文档
4. [agent] cross review 需求文档，fill in more context if necessary，评估 AI 实现的可能性，退回 PM if necessary
5. [human being] PM approve（暂不讨论跨团队任务，又或者那些由 agent 全权处理的任务，只需要由多个 PMs approve，或者 story point > 8 的情况）
6. [agent] 通过需求描述进行以下动作 6.1 [agent] 影响分析 6.2 [agent] 任务拆解 6.3 [agent] 技术设计 6.4 [agent] 提交代码
7. [human being & agent] 代码 review
8. [human being] 测试 -> 测试也应该有一套结合 agent 的流程，今天暂不讨论
9. and so on（部署，监控，等后续动作，今天暂不讨论）

Agent 获取了什么新工作呢？

在整个流程里，我们需要众多 agent，从上到下分别是：

1. 一个连接了知识库的 PRD agent
2. 一个具备知识库知识和代码审查机制的 review agent
3. 一个技术设计影响分析 agent
4. 一个实现代码的 coding agent
5. 一个代码 review agent（copilot）
6. and so on（部署、监控等后续动作，都应该有一些各自的 agent）

有些步骤需要人机协同，有些步骤完全可以在迭代开始前（或许在 AI-driven 的年代，迭代的概念也要被颠覆），或者是需求 finalize 的那个瞬间，由 agent 自主开始分析影响，到提交 PR。这里，50%-60% 的基础工作，都由 agent 代劳。这让我想起星际穿越里的塔斯，飞船上 80% 的基础工作它都有执行权力，在经过塔斯分析之后，它总会留给库珀一些总结性的选项和方案，帮助库珀决策。或许最后，我们操作 agent 的过程，就是一个语音指令，比如 merge、执行、通过 review 等。

被 Agent 挤压的空间

在这样的一个流程下，被挤压的空间有 6.1 ~ 6.4，开发不再处理简单的事务，开发甚至不再敲打 code merge 的命令行。

在这样一个流程下，TPM 完全被 agent 替代，这类简单的需求不再需要通过 TPM，而是通过完善的文档、及时的代码以及 agent 的能力来实现。（highlight，今天讨论的都是 1-8 分的简单 task）

TPM 和开发人员的工作重点，回归到复杂和垂直的业务逻辑之上。另一个趋势是，公司为了更有效地使用 AI，从而不再设计过于复杂的业务，或者将复杂业务拆分，从而尽量做到业务原子化，以减少错误的 agent 行动导致的不良后果。

创造出来的新机会

产品的角色从精心处理每一项工作转而开始维护文档，当然，这个过程也是配合 agent 一起完成的。为了确保知识库的完整和准确，TPM 会花费巨大的时间来 align 当前项目的业务需求和文档描述，尽量做到一一匹配。这不是一个一劳永逸的过程，而是一个融合在每一个小步骤里的工作，比如当我在 review 某个需求的时候，发现文档信息有误，我就必须立刻纠正它，比如某个产品上线后，我们要批量的把最新的产品需求更新到知识库中。

产品的角色的第二个转变是，从写需求转变为 review 需求。

产品的角色还需要持续维护和负责垂直的业务需求，某些需求的业务复杂度是远超 LLM 能力范围的，这类需求即使给了足够的上下文、足够的文档和足够的代码，它都无法被 LLM 完成，人类还是要继续在这里发挥作用。

只不过这个人类发挥作用的边际，会随着 LLM 更新迭代而发生迁移。

好像还是差口气

写到这里，我忽然觉得，我还是在 human-driven 的世界里讨论这个话题，为什么我还要在每个当前有的流程里安放 agent？我不应该是按 agent 舒服的方式设立一套机制，然后把人放在某个必须出现的节点吗？

不过，如果要讨论这样的话题，必须问自己一个问题：why now？为什么我要现在讨论这个话题？技术的颠覆是渐进的，我们团队从利用 ChatGPT 做 NL2SQL 以来，一直追逐着所有 AI 的可能性，到 2025 年中旬，我们的信心开始大增，AI 这回真的行了，做出来的东西真的能用了，而且不需要所谓的科学家介入，我们几个臭皮匠也能搞出一些智能的应用了。激动的同时也是紧张，或许将来就是慌慌张张也不一定，但我们是幸运的，一路见证人类这 100 年最重要的一次飞跃。