当AI代理的代码生成成本趋近于零，真正的高价值正从“写代码”向“写提示词”转移。然而，这个决定最终交付物的关键步骤，至今仍是工程师独自完成的“黑箱作业”——团队只有在合并PR时才能一窥究竟，错失了早期对齐的最佳时机。
代码廉价，提示词成为新核心？
Hacker News上一位开发者的观察直击要害：“既然代码现在如此便宜，真正的工作变成了你交给AI代理的规格、上下文、计划——也就是提示词。那里才是决定实际构建什么、如何构建的地方。” 这与传统软件开发流程形成了鲜明对比：过去，设计文档、架构讨论、代码审查都是团队协作的节点；如今，当开发者面向AI编程时，最关键的决策——如何描述需求、提供上下文、分解任务——却完全退回到个人工位。
GitHub、Cursor、Copilot等工具的普及，让工程师能在几分钟内生成数百行代码。但提示词的质量直接决定了AI输出的质量：一个模糊的提示词可能引发方向性错误，而一个精心构造、包含边界条件和上下文约束的提示词，则能产出几乎无需修改的代码。这意味着，提示词本身已经变成了新的“设计文档”。
个体孤岛：PR之前无人知晓
“你独自编写，你制定的计划是本地的、私密的，你的同事只有在PR被打开时才能看到结果。”这位开发者指出。在一个团队中，这恰恰是“对齐”应该发生的时刻——但如今它成了团队协作中唯一缺失的环节。
传统开发中，需求评审、技术方案评审能确保团队对“做什么”和“怎么做”达成共识。而在AI辅助开发中，工程师往往在本地反复调整提示词，直到得到满意的代码输出，然后直接提PR。其他成员看到的只是最终代码，却无法知晓提示词背后隐含的假设、权衡和上下文。一旦发现问题，返工成本可能很高——因为你无法直接“讨论提示词”，只能讨论代码结果。
这种模式带来的问题包括：
– 知识孤岛：提示词中蕴含的领域知识、边界处理策略无法被团队复用。
– 认知偏差：个人对AI模型行为模式的“经验”可能不准确，却没有同行校准。
– 对齐滞后：直到代码提交，团队才发现方向不一致，此时修改成本已经上升。
Zero Alignment：协作提示词的雏形
GitHub Next近期展示了一个名为Zero Alignment的原型，正是针对这一痛点。“它非常接近这种协作体验，”开发者评论道。该原型允许团队成员实时查看彼此的AI工作流——包括正在使用的提示词、AI生成的中间结果，以及操作序列。在这个环境中，任何人都可以随时介入，调整提示词或提供反馈，从而在代码生成之前就完成对齐。
这个理念与“共享编辑器”类似，但核心从代码转向了“驱动AI的指令流”。它暗示了一种新的协作范式：不再只审查代码的历史提交，而是实时审查“AI对话”本身。如果团队能在提示词层面协作，那么每个人都能理解决策依据、重复有效模式、修正错误假设。
为何尚未普及：工具、文化还是效用？
开发者提出了一个开放性问题：“为什么这还不普遍？是因为缺少工具，文化习惯，还是协作提示词根本没用？”
从工具层面看，目前主流AI编程工具（如Copilot、Cursor）仍然以单用户工作流为核心，缺少开箱即用的多人协作功能。虽然版本控制系统可以保存prompt文件（如.claude/instructions），但缺乏实时协同、评论、对比等体验。同时，提示词本身是高度依赖模型的“流体”——不同的模型、温度参数、上下文长度都会影响输出，这使得“提示词协作”比代码协作更复杂。
从文化习惯看，软件开发长期强调“个人贡献者”效率，工程师习惯于独立解决问题。共享提示词可能被视为暴露“不成熟的思考过程”，或者被认为是“额外的工作负担”。团队中尚未形成“提示词应该像代码一样被审查”的共识。
最后，协作提示词究竟能否提升整体效率？或许对于高度重复的任务，个人优化已经足够；但对于复杂、需要多角色知识输入的场景，早期对齐确实能减少返工。GitHub的原型如果证明有效，可能会促使行业重新思考AI辅助开发的协作标准。
结语：提示词协作是下一波生产力杠杆
当AI代码生成变得像呼吸一样自然，人类真正独特的价值在于“提问”——即设计出高质量的提示词。让这个环节从个体孤岛变为团队协作，可能是软件开发效率的下一个关键杠杆。工具在进化，文化需要适应，而早期实践者或许能先一步看到不一样的风景——那里不再是代码的快速生成，而是智慧的集体涌现。