Agentic Engineering 的一些心得

5 月 23 日
 383394544

3 个月前从 Antigravity 入坑 agentic 开发,后来转 claude code + codex ,一点踩过的坑和心得分享。

核心原则

踩过的一些坑、一些建议

2933 次点击
所在节点    程序员
9 条回复
zbinlin
5 月 23 日
我是先设计架构,让它输出到 arch/
然后开一个 session 进行 feature 开发,
每进行一个 feature ,先让它读架构,输出到 specs 里,
然后再开一个 session 开始 task plan ,让它读 spec ,输出 tasks 里,
最后再开一个 session ,开始读 task 进行开发,开发完后让它总结到 results 里。

这样做的好处是,每个 session 的 context 都尽可能小,每个 feature 都有文档记录。

现在的问题是,这些操作比较繁琐,还不能自动化起来
383394544
5 月 23 日
@zbinlin 你这个工作流太长了,每次都会丢一点精度。让 "每个 session 的 context 都尽可能小" 不是好处,是坏处。现在的 Opus 4.7 上下文窗口很大,完全可以 handle 。
383394544
5 月 23 日
@zbinlin "每个 feature 都有文档记录" 没意义啊,那些东西你又不看、agent 也不需要,单纯制造中间商抽成而己。如果你真的想记录,用 pr 纪录和 issue 追踪就好了。我现在 cross repo 的问题都让 agent 把问题发到另一个 repo 的 issue 上,让另一个 repo 对着 issue 和自己的代码(有必要时看源 repo 的代码)改。
c0xt30a
5 月 24 日
@383394544 我这边使用经验跟 OP 不一样:即使是 max 推理能力下,过了 200K 之后 claude 能力会退化的非常严重,丢三落四。所以拆开多个 session ,然后定义每个 session 的边界之后,一个一个来才能达到最好的效果。我的感觉是 1M 的 ctx 更多是噱头,实用性不是非常高。
c0xt30a
5 月 24 日
claude 有一个 codex 没有的问题,逐个 session 开发的时候,前边的 session 经常性的会偷取后边 session 的任务,所以一定要在 prompt 里严格禁止。
383394544
5 月 24 日
@c0xt30a max 不好用(它会全量塞所有前文进 context ),我都用 xhigh 。

任务我都是用 superpowers 的一条龙 brainstorming → writing-plan → subagent-driven-development 。

subagent-driven-development 会根据 plan 拆好的任务按顺序用 sonnet 写代码、haiku review 然后下一个,全部做完后再 self review 才交付(交付完我会让它先提 PR ,然后叫 codex 审 PR )。

superpowers 的 subagent skill 真的好用,现在我其他任务需要 subagent 的也会用它(例如同时翻译多个 i18n ),它能避免 cc 原生 subagent 的"偷任务"竞争。
383394544
5 月 24 日
我也会人肉拆需求,一次让 cc 完成的需求都是恰好大小的。我对我的项目架构很清楚,知道怎么分阶段迭代。
zbinlin
5 月 24 日
@383394544 这是给 AI 看的呀,以后如果有问题,直接让它读文档就可以了。
zbinlin
5 月 24 日
控制上下文大小,一来是为了防止上下文爆炸,二来是为了省 TOKEN

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1214943

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX