AI时代，程序员交付的不仅仅是代码？

Linus 那句 Talk is cheap. Show me code. 程序员交付的不仅仅是代码？" src="/uploads/images/179.jpg"/>

过去，代码是最硬的交付物。它能编译、运行、测试、上线，也能诚实暴露问题。

但现在当 agent 可以在几分钟内生成一组实现、补测试、改 bug、跑命令、读文档。真正的工程问题开始从“你能不能写代码”转向：

换个角度新的 show me code 可能是：

Show me system.Show me boundary.Show me prompt.Show me tests.Show me logs.Show me rollback path.

Agent 不是聊天框，而是行动程序

Agent 更像一个由语言驱动的闭环行动程序。它通常包含这方面，

• 说到目标，要完成什么。
• 上下文的观点是，它知道什么。
• 至于工具，它能调用什么。其实，
• 权限的观点是。它能改哪里不能改哪里，
• 反馈这方面，运行结果、测试结果、使用者反馈。
• 说到记忆，它如何延续任务。
• 停止条件的观点是。什么时候算完成，什么时候必须停下。

如果缺少这些边界，agent 很容易把“看起来合理”当成“真的正确”。

这也是为什么很多 AI 编程体验会出现两极分化：简单 demo 非常惊艳，复杂工程却很容易发散。问题不一定是模型不够聪明，而是程序边界没有被定义好。

Prompt 不是一句话，而是工程协议

从比如这句来看。

帮我调整这个项目。

它几乎没有工程边界。

什么叫调整？性能、可读性、安全性、包体积、架构、使用者体验？能不能改 API，能不能引入依赖？怎么证明有效，失败时继续试还是停止？

更可执行的说法是：

目标：降低订单接口 p95 响应时间。至于约束，不得改变公开 API，不得修改鉴权逻辑。至于优先级，先检查 SQL 查询和缓存方法，再考虑代码结构。至于验证，必须运行现有测试。并补充一个 benchmark 或 profiling 结果。输出这方面，列出变更文件、风险点、验证结果。停止条件这方面，如果无法证明性能提高，停止并说明原因。不过，

这不是“把 prompt 写长”。这是在定义可执行边界，老实说，

好的 prompt 应该同时回答：

• 什么不能做？
• 成功如何判断？
• 失败如何处理？
• 哪些动作需要人类确认？

一个可用的 Agent 程序。 应该像小型操作程序

的 agent workflow 至少要有这些能力：

1. 任务调度的观点是，哪些事情串行，哪些可以并行。
2. 从权限控制来看。哪些文件能改，哪些命令不能自动执行。
3. 从工具接口来看，搜索、测试、数据库、部署、监控如何调用。怎么说呢，
4. 上下文管理这方面。只给它需要的信息，避免把噪音塞满窗口。
6. 至于错误恢复，失败后如何回滚、重试、降级或求助。
7. 验证机制这方面，用测试、类型检查、lint、benchmark、review 证明结果。

操作程序的价值不是替进程思考一切，而是提供稳定边界。进程可以运行，但不能破坏内核；程序可以申请资源，但不能无限占用世界。

Agent 也一样。

我们不能把它当神，也不能只把它当脚本。真正有效的方式，是把它从一团聪明的可能性，逐步熵减成可靠的程序。

程序员的角色会发生什么变化？说起来，

什么是这个任务?什么是正确，什么是边界?什么可以交给 agent?什么必须由人负责，

代码会便宜,判断会更贵

• 定义问题的能力.
• 判断方向的能力.
• 设计边界的能力.
• 建立验证的能力.
• 在速度暴涨时知道何时停止的能力.

Show me prompt that defines task.Show me context that supports judgment.Show me tools agent can safely call.Show me tests that prove result.Show me logs that explain process.Show me boundary that prevents disaster.Show me system that can repeat success.

---