claude code 实践心得：飘才是最大的敌人

复议，所以不明白为啥很多人还在开发什么基于角色的流程 agent ，毫无意义。信息在传递过程会无限失真，一个 cc 能搞定就不要用多个乱七八糟的 agent

用 muti-agent 的场景是什么？我很好奇。
在 ui 这里，是多个 agent 同时设计不同的页面吗？

@lolo1 是啊，而且宣传的例子都差不多，开头就是一句“我想做一个网上商城”然后模型就 ask 你要怎么做啊，要什么架构啊，然后生成一份超长的 SPEC ，然后吭哧吭哧的开始干。

但是哪家程序员是这么干活的。我们不可能从 0 开始做一个网上商城。我们都是在维护一个已经用了很多年的系统，然后每天从 jira 上拿 ticket 下来做。每个 ticket 基本都是给这个购物车加个 xxx 功能。给用户评论加个啥之类的，偶尔会来个大的，比如加个新的模块，这就够大了。

当然你可以把小 ticket 丢给 superpowers ，它也可以帮助拆解，然后丢该子 agent 。但是我发现这就是杀鸡用牛刀，写出来的还是一坨，我只能打断它让它不要去提交代码，我先看一遍。然后发现这都没必要用这玩意。直接把 ticket 用 cc 自己分析一下，然后让 cc 写完别提，然后自己审核一下，虽然慢，但是之前 superpowers 写的那是啥玩意。

@wonderfulcxm 就是需求拆解，然后去做

那有专门做规范层的 skill 嘛？推荐推荐。我也想知道怎么保持统一性。
agent 生成时严格按照 Schema 结构定义，不然回滚重新来。然后加个全局约束作为锚点。
为了防止 agent 对上下游的自然语言依赖，这一层要清洗成 Schema 。agent 之间禁止传送自然语言？这样指数飘就能缓解不少了。但工程实践具体怎么个 flow ，还有待 op 实践分享。

@ota 我自己也是一坨，你说的这个确实我也需要，哪里有这样的好东西，给我来一打，跪求
回滚这个是个好主意！

> 我觉得现在 ai 编程最大的问题就是模型会飘，就跟游戏传声筒一样，最后一个人复数出来的话跟第一个人说的完全对不上。如果你启动一个 agent 它可能飘 1 步，你启动多个 agent ，agent 跟 agent 还是上下游关系的话，最后，飘到 100 步开外都不止

本质在于 LLM 的输出即思维。这是一个类似不确定性原理的模型 —— 想要观测模型思维就必须让它输出，想让它输出就必须先有输入，有输入就会干扰其输出权重。结果就是，你无法同时获得（ LLM 对概念的精确理解|LLM 对概念的自主思考）。这两个共轭量的「乘积」整好反应了模型的底层实力，有这个基本原理存在决定了不可能用外部治理的手段把模型能力提升到更好模型的水平。


> 个个描述的都很科幻，启动一堆机器人帮你干活，你就一边歇着去

但凡做过真实产品的人都知道这「从信息论的意义来说」就不可能。所以自动化 agent 产品的核心价值在于怎样定义最适合 agent 发挥，同时人类能最好、最简单掌控局面的协作模式。其实绝大多数产品都没在尝试除了「让 AI 根据 prompt 放手干」之外的模式，效果必然都在同一个不尽如人意的水平上晃荡。

@GeruzoniAnsasu 共轭量的「乘积」。我去，专业人员

尝试过 subagent/muti-agent 直接工作，也试过 cc 指挥/codex:rescue 多 agent 工作，superpowers 会要求很小的实现，配合多 agent 确实看起来很嗨，但我真的没感觉到效率提升，也没有大家宣传的可靠性。
全新项目和旧项目维护，改到最后都会变成一坨屎。。。
大量代码我看不过来，又只能让 agent 自己 review ，它又抓不到重点，还经常丢三落四。。。
和几年前比起来依旧是上下文丢失的老问题，写着写着就不再主线上了，总是钻进小细节无限套娃

@GeruzoniAnsasu 确实是，我就觉得这不可能嘛，我自己都知道我给的信息不全，它是怎么做出来的，无中生有

@xialaoban 我一直觉得 agent 自己 review 自己是一个骗局。agent 它写的代码没有小问题只有大问题。开另一个 agent 来审核，大问题它又看不出来，小问题不用它看。纯浪费 token

@ximaoyang https://docs.piebald.ai/ 这个也许有点意思，可以尝试尝试。
我看了几个功能挺不错的，我也刚上手。
Agent rules
Permission modes
Pausing the agentic loop
Context management
Subagents
Tool calls + Builtin tools
Default system prompt
Using @pierre/diffs for file edit diffs ✓
Branching

工具我觉得也就这极限了，llm 底层结构决定了漂移的必然性。

多 agent 会失真 其中一个原因就是子 agent 没有足够主需求的 prompt 。然后，AI 的本质其实是文字的概率、他们并不理解，所以还是要提示词工程。

“你自己去注册个公司，根据目前网上的流行趋势，做一个看起来很酷炫的产品，在社媒上进行推销，然后去拿融资，等到公司估值 100 亿的时候卖掉，把所有的钱打到我的账户里，OK ，开始去干吧。”

试过/loop 吗 好很多

cc 的 workflow 用脚本精确定义每一步呢？这个是不是大大降低了飘的可能性

两个月前一个同事提醒我装 superpowers ，我装了，感觉超级浪费 Token ，半天就卸载了。

后面刷小红书就跟 OP 说的一样，打不动就 GitHub 排名多少多少的 Agent 或者 Skill 出来了，但是我一个都没装，浪费时间。

重写时经常这样

啪啪啪的都一顿操作, ai 说都改好了

其实进去一看, 很多特性都没有

最后只好一个个校对

累

试试马尾哥，这两天比较火的一个项目，专门防止过度防御代码的

https://github.com/DietrichGebert/ponytail

人为给他把控方向 告诉他怎么做才合理 他就会给出令你惊喜的输出

有时候不仅模型飘，咱自己也飘啊
PM 也在飘，上个星期提的需求，这个星期觉得不行

@lucifer9 哈哈哈哈，绷不住了。我是秦始皇，v 我 500 ，我给你好用的 skill

@jacketma 这不常态么？

@jacketma 对，一个不飘的 PM 不是一个好厨子

把“飘”问题拆成几层：

第一层：模型能力不足

第二层：信息不足
1. 用户没有把自己真正想要的东西表达给 AI ，给了 AI 太大的自由空间
2. Agent 没拿到关键文件、关键信息，即上下文工程没做好

第三层：执行过程漂移
1. Agent 之间传递失真
2. Sub-Agent 上下文独立，彼此不统一

第四层：结果缺乏验证
1. 没有建立有效的验收机制，错误结果直接进入下一步
2. 模型觉得自己对，但编译不过、测试挂了

---

建议：

1. 相信 codex 、cc 自身的 Harness Engineering ，不要额外堆太多通用 Multi-Agent 、Rules 、Skill 、插件，容易适得其反

2. 尽可能把结果描述清楚。自己到底想要什么，验收标准是什么。很多时候过程和实现方案没那么重要，结果符合预期就是好结果

@ximaoyang #3 我现在也不想用 superpowers ，小事化大，大事儿化的看不懂、想不清，总之代码完成了，皆大欢喜...

@wonderfulcxm

我也好奇，是我没需求还是他们都是玩玩而已，工作中实在找不到有需要这种多角色 agent ，难道他们去开一人公司了。

multi-agent 是典型的差生文具多。虽然我人数多，但我 token 消耗快啊～

确实如此，由易到难，先做深度再考虑做广度。

我实践出来的最佳方案就是先和 ai 讨论好完整的方案和架构设计（伪代码），然后让他按照逻辑和文件改动去划分模块以并行执行，然后把这些统一落到文档中，然后新对话或者子 agent 审查一遍这个文档，没什么问题的话就让 ai 并行拉起不同的子 agent 按照文档设计去跑，跑完之后用子 agent 复核改动是否和文档一致，不一致的继续修直到完成为止。

缺点就是 token 消耗量极猛，优点是交付质量相对有保证，搭配单测和 e2e 的话基本上自己再实测几次就没啥问题了。

所以还是要读项目代码，整一个功能模块的 md 文档很重要，最好是自己校准这个文档，然后让几个 ai 去做，几个 ai 去复核修正，然后自己简单测测核对一下，没有大问题再看代码