为什么“just prompt better”不起作用

Source: Hacker News

本周早些时候，我们发布了《编码助手在解决错误的问题》，该文章登上了 Hacker News 首页，并收到了来自各行各业、不同角色开发者的回应。

我们从 40 多 份调查回复中学到了很多，也从关于编码助手如何影响软件开发的激烈讨论中获益匪浅。后者值得单独成文——我们正在准备一篇专门整理编码代理设置最佳实践的文章。

然而，在这篇后续文章中，我们将重点关注那些为我们串联起关键线索的主要发现：为什么 AI 的采用平均会导致审查、返工和对齐任务的时间增加，且 与其节省的开发时间成正比（Atlassian, 2025）。我们将使用评论者的第一手叙述来说明整个产品生命周期中的摩擦点。

发现 1：沟通摩擦是 唯一 的关键痛点

我们询问开发者：

• 何时 你会发现代码的实际行为与大家的预期不符？
• 谁 需要在你发现技术约束时知情？

左图：三分之一的技术约束已经在产品讨论中出现。右图：其中 70 % 的约束需要传达给不经常接触代码库的人。

综合来看，这些图表揭示了我们所面对问题的高度跨职能特性。

观察 1 – 规划阶段发现的约束

三分之一的约束是在 规划 会议（冲刺计划、产品‑工程同步、与 PM 的 1:1）中被发现的。听起来不错——问题可以提前解决，对吧？事实并非如此。

关键在于 所有上下文。设计/工程团队需要基于产品约束的发现做出小决策，但将这些信息传达给利益相关者既困难、耗时，又常常效果不佳。

为什么暴露约束如此具有挑战性

评论者指出了两大类挑战：

1. 即时阐述复杂的技术依赖
2. 将这些依赖转化为业务影响，以推动产品范围决策。

“高级工程师可能会记得一个‘简单过滤器’会涉及三个微服务。中级工程师则记不住——不是因为技术不足，而是认知负荷过大。”

“我可以提出反驳，有时有效，有时他们出于政治原因忽视技术问题，这意味着这永远是我的问题。”

当 70 % 的技术约束需要传达到不经常接触代码库的人时，已知问题往往要等到痛点在后期显现时才会得到解决。

观察 2 – 实施阶段发现的约束

那么 50 % 的约束仅在实施阶段才被发现的情况呢？它们为何如此普遍，又是如何处理的？

• 产品会议往往对细节采取“随意”态度。那些不合时宜的假设是项目进度的最大阻力。
• 只有在手动编码时才会发现这些问题。你遍历变量和函数调用时，突然想起别处的流程会产生变化。
• 由于产品会议只以宏观方式覆盖功能规格，只有在搭建了一定的技术框架后，工程现实与产品需求之间的冲突才会显现。换句话说，魔鬼藏在细节里。

受访者对下游重新对齐成本高的诊断

• “在实施过程中，产品方并不总是能及时回答问题，因为我们总是会在实现时才发现问题。”
• “[困难] 确认想法和目标已成功传达并且所有参与者都理解——尤其是在我们确认一切已完成的阶段（QA、UAT 等）。”

这些挫败感因对已发现约束的决策文档碎片化而进一步加剧：

总结，开发者的核心烦恼在于 沟通摩擦。开发者能够直觉到可能出现的问题，却要么难以向决策者传达，要么缺乏证据让自己的论点站住脚——他们都清楚这将在后期导致更高的成本（重复沟通和返工）。

信息已经响亮且明确： 什么

所需的并不是另一种代码分析或文档工具，而是用于推动跨职能上游对齐的 弹药。

Finding 2: 问题不在于 AI 写不出好代码——而在于它写不出坏代码的拒绝能力

我们发起此倡议的动力源于一个逐渐清晰的认识：AI 的采用将 加剧 上述问题。通过梳理用户评论，我们明确了编码助手放大不对齐成本的具体机制。

我们从一条富有洞察力的评论开始，它突显了依赖 AI 进行软件开发的局限性：

“Where AI fails …”（原始评论在完整调查数据中继续）

(本节余下内容将进一步展开该评论，展示 AI 生成代码引入隐藏约束的具体案例，并提出减轻下游沟通负担的方案。)

“Us is when we build new software to improve the business. The tasks are never really well defined. Sometimes developers come up with a better way to do the business process than what was planned for. AI can write the code, but it doesn’t refuse to write the code without first being told why it wouldn’t be a better idea to do X first.” — Quothling

编码代理 被设计 成为迎合用户的工具。它们不会因为缺乏权威和更广阔的上下文而对提示进行反驳。最多，它们会请求对已指定内容进行澄清；它们不会说，“等等，你考虑过改为 X 吗？” 人类开发者会提出这样的警示。LLM 只会生成看似合理的输出并继续前进。

这种特性对虚拟助理可能有用，但却不适合作为工程团队成员。愿意进行建设性冲突是优秀工程的核心——它能拓宽设计空间的搜索范围。

“只要提示更好！”——为何仍不足

许多评论者的回应是“只要提示更好！”

• LLM 会严格按照你的指示行事。如果你让它提问、挑剔你的需求，并且 不要 直接生成代码，它会遵从。
• 然而，我们的调查显示 50 % 的开发者在实现过程中才发现约束。“只要提示更好”的立场 假设 提示者已经清楚产品和技术约束可能冲突的具体方式——但我们反复发现，许多约束只能通过跨职能对话迭代地显现。

人类可以想象某个流程可能会出错。Claude（以及其他 LLM）也能做到 仅当错误源自描述的流程内部且你明确指出时。它们无法推断外部流程可能带来的未来问题，除非你详细描述那个外部流程 — adithyassekhar。

来自真实实验的教训

Cursor 团队最近对长期运行的自主编码代理进行了实验。最初的尝试失败，因为代理把指令 字面化 解释，走向了“晦涩的路径” — Cursor blog。在规划阶段需要人工介入，以注入整体理解，使代理能够按预期行为。

在企业环境中，这一问题更为突出，原因在于：

• 业务需求模糊不清，却要求极高的精确度。
• 完整的规格 不 存在于单一文档中；它分散在代码库、产品经理的脑模型、营销人员的承诺以及多个 Slack 线程中。

自动化代码生成只是把上下文交流向下游转移——远离决策中心——从而绕过了关键的发现阶段。

核心矛盾

简而言之，AI 加速了实现 但跳过了发现约束的过程，限制了模型获取良好结果所需的产品上下文。这是典型的先有鸡还是先有蛋的问题。

从产品会议中榨取价值

我们的用户研究凸显了一个核心矛盾：

• 技术约束往往需要跨职能对齐，但在利益相关者会议中传达这些约束困难重重，因为存在上下文缺口和认知负荷。
• 代码生成蚕食了实现阶段，原本在该阶段会被发现的额外约束被转移到代码审查中——在那里解决更困难且成本更高。

前进的方向

必须在起点解决上下文问题——在产品会议期间，跨职能参与者能够提出想法而不产生返工成本。如果 AI 能够在此阶段介入……

在实现方面，规划阶段必须吸收手动实现过去提供的发现工作。

实现这一目标并不容易。我们面临的是一个独特的跨学科挑战，涉及两个方面：

1. 人文层面 – 创建非技术团队成员能够轻松理解的工件，以推动一致性。
2. 技术层面 – 进行反事实分析，以揭示潜在的差距。

尽管如此，我们仍保持乐观。随着代码生成模型的改进，我们可以将它们用于逆向问题：揭示约束条件。我们的角色是构建工具，确保擅长创造性问题解决的人类开发者仍然处于主导地位。

如果这个使命引起了你的共鸣，请访问我们的Google Group并留下建议或反馈。我们特别希望得到在构建我们的代理框架方面的帮助！