云栈社区»论坛 › 站务中心「 Forum Service 」 › 我的实践：从手写代码到让Claude/OpenAI生成，再用‘进化论’挑 ...

发回帖发新帖

3875 积分	0 好友	570 主题

发消息

我的实践：从手写代码到让Claude/OpenAI生成，再用‘进化论’挑选

发表于 5 小时前 | 查看: 3| 回复: 0

最近一个月我持续深入地使用 Claude Code 和 OpenAI Codex 等产品，认知又有了一些新变化，想跟大家分享一下。

“进化论”程序员

现在很多文章和视频都提到过一个想法：在 LLM 生成代码越来越便宜、快捷的今天，我们更倾向于让 LLM 多次生成代码，而不是只生成一次，如果结果不好就放弃或依赖大量手动修改。

这种做法很像“进化论”。比如，我们可能会把同一个指令交给多个不同的 Coding Agent，或者在单个 Agent 里启动多个 git worktree 或沙箱，让他们完成相同的任务。然后，我们再根据产出挑选最满意的那一个；也可能全部丢弃，调整指令后再来一遍。

当 Agent 生成的结果不符合预期时，很多人可能会习惯性地打开 Cursor 进行局部修改，或者在同一个对话里持续提出修改意见。但经常会遇到对话上下文过长后，模型表现下降、陷入自我修复循环的问题。因此，我通常会做一个简单判断：

当问题是局部且可定位的，比如对特定函数、测试用例或代码风格进行少量修改（预计改动<20%），可以考虑在对话中提出精确需求，继续迭代。
除此之外的绝大多数情况，包括需求不清晰、设计不完善、涉及多文件修改或对话上下文过长等，都倾向于修改指令后重新生成。

为此，我特地看了看大家常用的基准测试，包括 SWE Bench、Live Code Bench、Aider Polyglot Bench 等。发现它们大多是用户单轮提出需求，由 Agent 自行多轮调用工具来完成任务，很少有人类多轮反馈实现一个任务的场景（构建这样的数据集也更难）。所以，目前模型不太擅长多轮交互的工作模式也就好理解了。

总结一下，这背后的认知改变包括：

“写代码”不再是一项昂贵的任务，可以随时生成，随时丢弃。这一点至关重要！
提前做完善的设计，甚至把需求彻底想清楚，这本身就很有难度。传统开发中也常常需要“边做边设计”，或者提倡敏捷模式。而“代码生成”本身就可以帮助我们优化设计。
大模型天然的随机性、集成算法的有效性，乃至进化论思想本身，都非常契合这个思路。
在代码生成成本极低的今天，人类的价值更多体现在“品味”上。为何不最大化品味的价值，减少对代码的“微观管理”呢？

更多的模型 Token 加上更优秀的品味，等于更高的智能。

控制模型的注意力

这也是个很有意思的发现。虽然 “Attention is all you need”，但模型的注意力其实是非常有限的，就像人类的认知负荷一样。举几个具体例子：

当你强调模型的“指令遵循”时，往往会扼杀它的批判性思考。比如你告诉它“这里的类名可以叫 UserService，或者你帮我想个更好的名字”。那么超过90%的情况，它都不会挑战你的命名，而是直接遵循。
当给模型更多的 Few-shot 示例时，它会进入复读机模式，大大削弱推理和创造能力。这一点在 manus 分享的文章[1] 里也有提到，可能仅仅是一个 Token 的差别，模型就切换了行为模式。
当你给模型一份很长的需求列表时，它往往会产出一份总体平庸的结果。我个人体验最明显的是在做代码审查时，如果直接给一份详尽的代码规范文档，它往往找不出什么真正的实际问题。

这些问题或许与 Next Token Prediction 的监督学习方式有关。一方面，模型只是在优化预测误差，而不是为了完成复杂任务；另一方面，更综合场景的数据集也确实更难构建。虽然强化学习的引入应该有很大帮助，但目前可能还处于早期，更多是解决明确具体的代码、数学、调研问题，尚未深入更复杂细微的真实世界场景。

所以，这也是为什么我在之前的文章[2] 中建议做任务拆分，以及在利用 Agent 做代码审查时，也会拆分审查角度来分别触发。比如，我会让 Agent 在一次任务中专门审查代码是否精简，这时它常会建议减少函数抽象，直接内联；而在另一次任务中专门审查单一职责和模块化设计，这时它又会建议做很多抽象和拆分。具体如何选择，就又到了体现人类品味的时候了。

推广来说，为什么可以用 LLM 来做评审，自己评判自己就能提升效果，好像并没有输入额外信息？这背后也与生成验证差距，以及利用了模型不同潜在空间中的“注意力”，从而发挥出更高的“集体智慧”有关。可以说是一种“人肉测试时缩放”。

是否需要详尽的规格说明？

有不少人提倡，既然代码生成变得容易，对人类而言编写规格说明就更加核心。甚至像 Kiro[3] 这样的产品，直接把需求、设计和任务生成的工作流作为核心功能内置了。也有很多人建议把规格说明或相关文档放入项目，与实际代码持续同步迭代。

但我在实际使用中发现，过度强调规格说明，可能容易陷入 AI 时代的瀑布式开发陷阱。软件开发核心还是一个探索和学习的过程，很多功能与设计都需要在开发过程中不断调整。而且，如果不小心因一句话需求自动生成了几百行规格说明文档，会使整个任务的批次体积膨胀，对 Agent 的工作时长、后续人类需要审查的精力，以及修改优化的成本，都会大幅上升，不利于整体吞吐量。对应到上面提到的注意力机制，详尽的规格说明中往往包含非常具体的实现细节，会让模型进入“指令遵循”模式，反而失去了获得更好设计的创造力。

因此，如果你想使用类似的方法，目前需要格外小心一个功能规格说明的范围大小，尽可能控制在 400 行改动以内（经验值），同时也要避免太多具体的代码示例。我个人也更喜欢 Claude Code 这种计划模式加 TODO 工具的轻量级组合，或者未来通过子 Agent 来逐步扩展范围。在实际工作中，我很少会让 Agent 来生成具体的规格说明文档，而是：

当有具体设计问题时，直接与 Agent 讨论；
提出的需求不会过于具体（很多模型生成的规格说明甚至包含具体代码），更多是明确背景和一些验收关键点，避免限制模型自我探索的能力；
利用前面提到的“进化论”思想，让模型并行探索与工作，帮助我们理解设计细节；
关注少量修改的快速实现和选择，同时在审查中关注代码的整体设计和长期可维护性。

对于最后一点，即使有了 Agent，要做到规格说明与代码实时同步仍然非常困难。因此，我更倾向于“代码即文档”的思路，将各种具体的设计上下文通过命名、注释等方式“内置”在代码中。这样，Agent 能在“阅读代码”的过程中快速理解相关设计背景，并且在修改时也能更好地保持同步。而不是让 Agent 多走几步去搜索对应文档再做修改，这反而增加了它的工作难度。

从前述“生成代码变得更廉价快速”的思路来看，阅读代码（而不是文档）实际上也变得更廉价了。为了让 Agent 更好、更快地阅读代码，我们应该拥抱这种“就近上下文”原则。当然，一些共性的项目规范放在 CLAUDE.md 之类的规则文件里是没问题的。

关键要点：