成为决策者：在LLM时代掌控你的项目
要思考自己在LLM辅助工作中的身份：你是决策者、是领导者，而不是执行者。许多开发者可能都有过这样的经历：明明是一两行直观且容易修改的代码，让LLM修改却总是无法改对，最终只能自己动手。但更让人困扰的是，在LLM迭代数个版本后，这段代码很可能又被改回了错误的状态，而我们却浑然不知，直到测试甚至发布后才发现问题。
困境与根源：为什么LLM总把代码改回去？
出现这种情况，核心原因在于：LLM会选择统计上最常见的方案，而不是最适合你的方案。
我们的工作基于具体的需求和场景，而LLM基于统计数据开展工作，这里核心的问题是信息不对称。当你觉得"这个需求很明显"时，对LLM来说，它看到的只是成千上万个类似语境中的统计规律。
破局之道：从线性对话到树状决策
第一步：通过对话同步信息
当LLM生成的答案不符合预期时，不要只是简单粗暴地让它"重试"（虽然有时候确实有效），而是应该为它提供更多的上下文信息。
一个有效的做法是：从简单需求开始，要求LLM先不要生成代码，而是和你聊一聊需求和技术实现。在对话过程中，逐步提供更多信息，让LLM真正理解你的特定场景。
–> 作为决策者，沟通能力非常重要。这不仅包括与LLM的沟通，还包括与团队成员、产品使用者的沟通。 –> 虽然与他人的沟通中存在更多不可控因素，但至少我们可以控制自己保持谦虚和开放的态度。
第二步：用中间文档固化决策
使用上述方法时，你会自然发现一个问题：项目中的决策实际上是树状的，而你与LLM的对话却是线性的。
这时，一个非常有效的策略是：生成Markdown中间文档。
有了中间文档，我们就能弥补线性对话的缺陷。LLM可以随时访问决策树中任意节点的文档，了解当时的决策背景。更重要的是，我们应该使用树状结构来组织这些文档，这更符合真实的决策过程。
基于决策树的Markdown文档结构让我们可以无限完善项目决策记录，但显然无限细化是不现实的。这就引出了下一个关键：问题边界。
文档应该细化到什么程度？答案是因人而异的。当你与LLM的对话深入到你所关注的边界时（比如作为业余开发者或管理者，你可能不需要关注底层技术细节），就应该停止讨论，转而开始编码。
角色的进化：从Coder到决策者与审查者
这种工作流程与传统开发有相似之处：过去团队会产出详细的设计文档，然后交由开发者执行。主要区别在于，现在的"执行者"变成了LLM，而"决策团队"简化为LLM使用者一个人。
这必然导致一个结果：开发者的工作中，Coding时间会进一步减少（对我而言，这是需要遏制的冲动，需要逐渐适应），而规划、决策和结果审阅的时间会大大增加。
核心技能：如何审阅LLM生成的代码
我们需要把LLM看作"写代码极快，但经验为零的开发者"。因此，绝对不能无条件信任它生成的代码，而是要仔细审查。
基于这个前提，高效阅读LLM生成的代码很可能成为AI辅助编程时代开发者的核心能力之一。
问题是，阅读他人代码已经很困难，阅读LLM生成的代码更是难上加难，原因在于：
- LLM生成的代码通常缺乏完整的上下文
- 代码可能是正确的，但设计不优雅、可读性差
- LLM可能生成带有微妙逻辑错误的代码
同样重要的是，我们不应该学习LLM的编码风格，而是要小心验证它是否符合要求。
和任何技能一样，代码审阅需要刻意练习。以下是一些实用技巧：
通用技巧：
- 把代码跑起来，断点调试：这是最快最有效的方法。如果项目复杂，可以用LLM快速搭建测试DEMO（你会发现在这方面LLM出奇地好用）
- 用工具可视化代码结构和数据流
- 补充注释
- 尝试重构：使用更有意义的变量名，将大函数拆分为小函数
针对LLM的特殊技巧：
- 测试驱动：拿到代码后先测试再阅读
- 测试驱动：先写测试用例，再让LLM根据测试生成代码
- 检查代码与需求的匹配度：用注释标记每部分代码对应文档中的哪个需求（LLM经常过度发挥或遗漏需求）
- 关注模式：不要只看语法，要思考代码背后的模式和框架，比如为什么使用某个数据结构或设计模式。不要只关注"术"（怎么写），更要反思"道"（为什么）
后记
本文是我此前关于 LLM 思考的延续，上一篇文章可参见：🌱LLM基本原理及思考 - Klin’s Blog。
文中大部分观点和灵感来源于我于 2025 年 10 月 26 日 在 深圳·香港中文大学深圳研究院 参加的 深圳 Community Day 开发者的聚会。
特别感谢以下嘉宾的精彩分享，他们的见解是本文的基石：
- 亚马逊云科技资深开发者布道师 - Damon
- 亚马逊云科技副总裁 - Jeff Barr
- 亚马逊云科技资深布道师 - 郑予彬
同时也由衷感谢活动的所有组织者与分享者，是你们的努力促成了这次宝贵的思想交流。
–> 微信关注 开发者UserGroup社区，可以观看会议视频回放。