「写代码，还是写提示词」是伪命题吗？

这确实有点伪命题的意思。我觉得它触及了一个更本质的东西——我们到底在用什么方式跟机器交流。

我们来想一下是。写提示词的作用是什么？描述逻辑、定义边界、处理异常情况，这跟写代码的思维方式本质上是一回事。只不过一个用的是Python、Java、c++等编程语言的语法规则，另一个用的是自然语言的语义规则。他俩的目标都一样的：让机器按你的意图干活。

现在提示词工程里那些技巧，什么Chain of Thought、Few-shot learning，说白了就是在设计算法。好的提示词需要考虑输入输出格式、边界条件、异常处理——这不是跟编程思维一样吗？而且你看发展趋势，代码一直在变得更高级更抽象，从汇编到C到Python再到各种低代码平台；提示词呢，也在变得越来越结构化，YAML配置、DSL、各种模板。两边其实是在往中间靠拢。

边界还存在

我觉得这里最核心的差别在确定性上。代码给你确定的输入，除非你故意加随机性，否则输出是完全可预测的。而提示词不一样，同样的输入可能得到不同的输出，你需要用概率的方式思考问题。

调试方式也完全不同。代码报错信息很精确，可以单步调试、二分查找等方式都能找到问题出在哪。提示词的"调试"更像玄学，你得不断试探模型的边界，有时候改一个词就能解决问题，有时候改半天也摸不着头脑。

还有就是可组合性。代码里函数和模块可以精确组合，接口契约很严格。但提示词组合多个指令时容易互相干扰，上下文窗口也有限制。能力边界上，代码理论上图灵完备，能精确控制每个bit；提示词受限于模型训练数据，突破不了它的认知边界。

真正的分界线可能不在"写代码"和"写提示词"这两个动作上，而在于显式控制流和隐式语义推理的区别。比如说传统编程是"如果天气=下雨且温度<10℃那么穿雨衣+毛衣"，这是规则驱动。而提示词是"外面又冷又下雨，我该穿什么"，让模型自己推理出合理答案，这是意图驱动。

实际工作中怎么做

目前看是：人写提示词让AI写代码，然后人工review——是现在最靠谱的工作模式了。

这个流程有效是因为各自在做自己擅长的事。人擅长理解业务意图、判断边界条件、识别潜在风险；AI擅长快速生成样板代码、处理繁琐细节、提供多种方案。但review这一步绝对不能省，AI写的代码会有各种问题：逻辑漏洞、性能陷阱、安全隐患、过度工程，还有个特别坑的——引用根本不存在的库或API。

下面说一些我个人私货，不喜勿喷，可以直接跳过：

上次我看到一个人说：

看到用codex把上百个数据集转化成统一格式。震惊到说不出话来，code agent现如今已经今非昔比

这样的话我也震惊了：

1. 数据集大小未知

如果是100个各10行的CSV文件,任何文本编辑器都能处理，sklearn的那些数据集都有小几百。如果是100个各10GB的数据集,就完全是另一回事

2. 多模态数据集不可能格式统一

图像、音频、视频、文本、表格数据的"统一格式"根本不存在，即使只是结构化数据,不同行业也很难真正"统一"，就光时序数据各种外生变量就不可能统一

3. 小数据集=文本处理问题

只是小型文本文件,用pandas写几行代码就搞定,没什么可炫耀的

4. 大数据集=简单预处理

如果真是大规模数据,那可能只是写了个简单的ETL脚本

5."统一格式"定义模糊

什么叫"统一"?是统一字符编码?统一列名?统一数据类型?还是统一存储格式?不同的"统一"难度天差地别

6.数据质量问题被忽略

格式转换是最简单的部分、真正困难的是:数据清洗、缺失值处理、异常值检测、语义对齐。如果只是机械转换格式,产出的可能是垃圾数据

7.没有提及数据验证

转换后的数据正确性如何保证?有没有单元测试?有没有人工抽检?

8.可复现性存疑

这100个数据集从哪来的?转换规则是什么?其他人能复现这个过程吗?

在AI领域,这种夸张宣传很常见,真正做过数据工程的人都知道,数据标准化是个极其复杂、需要大量领域知识和人工判断的工作,不是简单的格式转换。

我说这个例子的意思就是基本上就是一个吹牛博眼球的说法我们不讨论这个问题，我们讨论的是应该人工review的问题。

逻辑正确性（边界条件、空值、循环终止），安全性（输入验证、权限、敏感信息），性能（时间复杂度、不必要的循环），可维护性（命名清晰度、复杂度），还有依赖的真实性。这些在编程的时候基本上大部分都是单元测试要解决的问题，对吧。如果你prompt不写清楚，ai也只能做简单的测试，也就是代码对不对，而不是上面这些真正对于业务有用的检查，这时还是需要人工来进行review。

不过不是所有代码都需要同样严格的review。一次性脚本和原型跑通就行，抽查关键逻辑就够了。业务代码要完整过一遍检查清单，测试关键路径。核心基础设施和安全相关的代码就得逐行review，写测试用例验证，关键部分可能还得人工重写。

有个很有意思的地方：提示词写得越好，review负担越轻。如果你只是说"帮我写个用户登录功能"，AI会给你一堆不知道从哪复制来的代码，review要花很多时间理解和修改。但如果你说"用JWT实现用户登录，密码用bcrypt加密存储，token有效期24小时，返回标准RESTful格式，分别处理用户不存在和密码错误"，设置你画出个流程图给ai，AI生成的代码就会更符合预期，review主要检查实现细节就行。

最后

我觉得这个模式会继续演进。AI可能会在生成代码的同时生成测试用例（当然边界之类的还要人人工确定，毕竟AI也不知道你什么业务），会有自动review工具让AI检查AI，标注可疑部分给人确认。对关键逻辑可能会用形式化验证的数学方法证明正确性。迭代会更快，人只需要说"这里有bug"，AI自己找到并修复。

但人工review的最终决定权永远不能省，因为AI不理解真实业务后果，不承担责任，有些错误只有领域专家能发现。

回到最开始的问题，写代码还是写提示词不是个二选一的选择题：一端是纯手工编码，最确定最精确；另一端是自然语言对话，最灵活也最模糊；中间是结构化提示词，我觉得需要在这个墙上自己平衡，知道什么时候该用严格的代码控制，什么时候该用灵活的语义指导。