夜雨聆风你每天和 AI 聊天，其实已经在做一种新形式的编程。
你写一段提示词，AI 给你一段代码、一份文案、一张图片甚至一段视频。你改几个字，AI 的输出就变了。你补一段背景，它给的结果又突然变得更贴近你的项目。
在基于大语言模型的 AI 出现以前，这些输出是来自各种计算机上的程序。图片靠图像软件，文字排版靠编辑器和排版引擎，代码生成靠脚本或编译器。程序员写程序，计算机执行程序并给出结果。
现在可以做一个有用的类比：大模型像一台新型的计算机，提示词是写给这台机器的程序；大模型根据提示词生成内容，如同传统计算机执行程序指令后得到结果。
这个类比不是严格等价，但有助于加深我们对提示词和提示词编写的理解。
提示词的优劣之分，如同代码质量的差别
程序员写给计算机的代码，质量可能天差地别。好的代码结构清晰、边界明确、容易维护，甚至会被夸“像诗一样”。差的代码则是另一回事：变量名像临时凑的暗号，业务逻辑、接口调用和 UI 状态搅在一起，改一处牵三处。这样的一堆代码，常被嗤之为“屎山”。
写给 AI 的提示词也有优劣。下面这个就写得不好：
帮我写一个登录页面，要好看一点，能用邮箱和密码登录。这个提示词说得很模糊。AI 看到这句话，虽然也能给出东西，但它会被迫做很多猜测，比如：该用哪种技术框架？错误状态怎么展示？要不要移动端适配？......最后的结果可想而知，它可能也输出了一个看似完整的页面，但很难直接集成进项目：样式跟现有组件不一致，登录状态没处理全，错误提示像临时文案。
下面这段的提示词看起来就要好很多：
请在现有 React + TypeScript + Tailwind 项目里实现登录页。目标：用户输入邮箱和密码后，调用 POST /api/login，成功后跳转 /dashboard。上下文：项目已有 Button、Input、Card 组件，放在 src/components/ui；路由使用 react-router。约束：不要新增 UI 库；移动端宽度 360px 也不能横向滚动；密码错误时显示接口返回的 message。输出要求：修改 src/pages/Login.tsx，并说明你改了哪些状态处理。验收标准：邮箱格式错误时禁止提交；请求中按钮显示 loading；接口 401 时不跳转；成功后清空错误信息。它把“我想要什么”拆成了目标、上下文、约束、输出要求和验收标准。这样，AI 不用自己做很多猜测，也更容易在出错时被纠正。
AI 编程水平的高下，取决于清晰表达意图的能力
AI 编程的本质，是给 AI 写一份可执行、可验收的工作说明。过去软件开发人员要在需求文档、接口协议、测试用例和代码审查清单里表达的目标和要求，现在往往要压缩进一段给 AI 的任务说明里。
这和传统编程并不冲突。以前你为了把意图表达给计算机，要用计算机语言写语法正确、逻辑清楚的代码。现在你是要把意图表达给基于大语言模型的 AI，使用了自然语言。但如同人与人之间的沟通一样，你得把你要 AI 做的事情的目标、边界和质量标准说清楚，这样它才会成为一个靠谱的工程搭档。
所以，学习 AI 编程，重要的不是积攒神级提示词模板，而是训练清晰表达自己意图的能力。
Skill 和 harness，只是把表达变得更工程化
经常做 AI 编程的人很快会发现：同样的规则经常要重复说，同样的流程需要每次重建。于是就出现了 skill、agent 配置、harness 这类结构化做法。
Skill把一类任务的说明、流程、参考资料，甚至脚本，打包成可复用能力。比如“写公众号文章”可以有一个 skill，里面规定选题、资料、结构、正文、配图和质量检查等该怎么做。这样就需要每次把这些规则从头输入，只要补充本次文章的主题和约束，然后触发这个 skill就可以。
Harness 也类似，它把“AI 应该怎样工作”写进运行环境里。用户通过它表达工具权限、上下文来源、执行步骤、检查点、失败处理和安全边界等，把模型推理限制在规则框架之内。
但是，skill 和 harness 本身并不会替你表达意图。它们只是把意图表达形式从一次性聊天，改为了稳定结构。你仍然要说清楚任务目标是什么、哪些限制不能破、成功的判断标准是什么、出错时应该怎么处理。
这也是为什么同样一个 AI 编程工具，不同人用出来的效果差别很大。工具相同，模型相同，差距在于跟 AI 的沟通质量。一般人只会说“改好这个页面”，但有经验的人会说“保留现有信息架构，只修复移动端表格溢出；不要改接口；完成后跑 lint，并用 390px 宽度截图检查”。后者强的不是提示词更长，而是把工程边界、验收标准和禁止事项给 AI 交待清楚了。
把意图写清楚，是可以训练的能力
在 AI 编程中，好的表达通常有三个特征。
第一，让 AI 少猜。凡是你不希望 AI 自作主张的地方，都应该写清楚，比如技术栈、目录、依赖、接口、风格和禁止事项。
第二，让结果可检查。你告诉 AI 要“写得好一点”，这肯定是没法验收的；但如果你说“在请求中禁用提交按钮，401 显示错误，成功后进入 /dashboard”，这就有了验收依据。
第三，让返工有方向。当 AI 输出不对时，你能看出是目标错了、上下文漏了、约束被破坏了还是缺乏验收标准。这样，下一轮修改不是简单地向 AI 提示错误，而是要考虑是不是修正一下工作说明。
作为初学实践，你可以按微型需求文档的写作思路，为 AI 编程代理编写提示词：
任务：上下文：约束：输出要求：验收标准：不要做：刚开始写这六项可能会觉得麻烦，但磨刀不误砍柴工，它会减少 AI 猜错方向，减少后面反复修补的无效轮次。更重要的是，它会训练你在动手前先想清楚问题。AI 时代的软件开发，不会因为使用了自然语言就不需要工程能力。
