文章摘要
AI辅助软件开发的质量关键在于正确管理工作单元。新手常因未能提供适当上下文而效果不佳，而非模型智能不足。Andrej Karpathy强调，应将AI限制在“紧绳”上，专注于处理小而具体的任务。合适的任务单元大小能有效维护上下文，这是提升AI工具效果的最重要技术之一。
文章总结
AI辅助软件开发的质量取决于工作单元的管理
在AI辅助软件开发的实践中，正确管理工作单元是至关重要的。当我刚开始接触这一新兴领域时，尽管AI模型相当智能，但结果却不尽如人意。后来发现，主要瓶颈并非智能本身，而是如何提供正确的上下文。
Andrej Karpathy曾将AI辅助工程的工作描述为“给AI系上紧箍咒”。在AI代理独立操作代码的过程中，这意味着将任务分解为小块的具体工作。这种“紧箍咒”式的管理有助于确保AI在正确的上下文中生成代码。
合适的工作单元大小尊重上下文
“上下文工程”这一术语很好地解释了为什么管理工作单元是提高AI工具效果的最重要技术之一。它强调了AI生成代码时所依赖的“画布”。Anthropic的文档中提供了一个可视化示例，展示了上下文窗口如何随着每次生成而填充，最终超出窗口限制。上下文窗口的内容对生成代码的质量有着巨大影响。
如果上下文信息不足，AI可能会产生幻觉或生成与代码库实践不符的代码，尤其是在软件系统的集成点。相反，如果上下文信息过多，输出质量也会因缺乏专注而下降。因此，将任务分解为“合适大小”的工作单元，描述适量的细节，是改善上下文窗口、提高生成代码正确性和质量的最有效方法。
合适的工作单元大小控制错误的传播
假设AI代理有5%的犯错概率，在多轮工作流程中，错误会累积。如果任务需要10轮完成，成功概率仅为59.9%。因此，AI代理在每步操作中都需要某种“暂停并验证”的机制，以控制错误的传播。
根据METR的研究，GPT-5在执行2小时任务时的成功率约为70%，相当于每步操作的错误率低于1%。然而，现实世界中的任务往往更加复杂，软件工程项目通常具有路径依赖性和动态性，成功概率会显著降低。因此，将问题分解为可验证的工作单元，是管理错误累积的关键。
什么是“合适大小”的工作单元？
合适大小的工作单元应小而简洁，描述预期的结果，并且结果应易于人类理解。软件工程师已经定义了一种提供业务价值的工作单元——用户故事。用户故事以用户结果为中心，能够适应软件开发中的复杂动态环境。
大多数AI代理的“规划”模式虽然能保持代理在轨道上，但主要提供技术价值，而非明确的业务结果。因此，将项目分解为提供业务价值的小工作单元，是更优的选择。
StoryMachine实验
为了测试用户故事是否可以作为理想的工作单元，我们正在进行一项名为StoryMachine的实验。目前，StoryMachine的功能有限，主要是读取产品需求文档和技术规范，生成故事卡片。我们希望通过迭代，找到一种能够轻松构建有用软件的工作单元描述。
总之，AI辅助开发的实践应减少工作量，避免像赌博一样依赖运气。通过管理工作单元，我们可以更好地实现这一目标。
评论总结
项目管理的范围控制：评论1强调了项目管理中保持适当范围的重要性，引用：“Keep your scope as small as necessary, but no smaller.”（保持范围尽可能小，但不要过小。）
AI编码工具的进步：评论2指出，许多开发者尚未意识到AI编码工具的巨大进步，引用：“most SWE folks still have no idea how big the difference is between the coding agents they tried a year ago and chatgpt 5 paired with Codex or Cursor today”（大多数软件工程师仍然不知道他们一年前尝试的编码代理与今天的ChatGPT 5与Codex或Cursor之间的巨大差异。）
AI在代码审查中的优势：评论3认为AI在代码审查方面表现出色，但在执行计划时表现不佳，引用：“It’s amazing at reviewing code... But it can’t follow a plan worth shit.”（它在代码审查方面表现出色……但在执行计划时表现糟糕。）
任务总结与上下文管理：评论5建议在完成每个任务后进行总结，并在新任务中使用这些总结，引用：“summarizing a completed task and feeding it to a new context works better than staying on the same context for multiple tasks.”（总结已完成的任务并将其输入到新的上下文中，比在多个任务中保持相同的上下文效果更好。）
AI编码工具的局限性：评论6指出，使用AI编码工具时，表达需求和处理边缘情况非常困难，引用：“reviewing code is harder than writing code... The end result is exhaustion.”（审查代码比编写代码更难……最终结果是精疲力尽。）
传统代码管理工具的局限性：评论7认为，传统代码管理工具如Git和GitHub限制了AI代码生成工具的潜力，引用：“we’re probably seeing AI code gen tools being limited by the constraints being put on them by traditional source code management tools like git and GitHub.”（我们可能看到AI代码生成工具被传统源代码管理工具如Git和GitHub的限制所束缚。）
AI开发的灵活性与挑战：评论8强调，AI开发需要灵活应对不同的任务规模，引用：“doing things in small chunks is good. so is it doing things in large chunks sometimes.”（小规模处理是好的，有时大规模处理也是好的。）
用户故事与开发过程的脱节：评论9认为，用户故事或功能作为开发单位并不自然，引用：“I find user stories or features to be really awkward and unnatural units of work for building software.”（我发现用户故事或功能作为构建软件的工作单位非常尴尬和不自然。）