8.0
热点
AI SCORE
编程提效2026-08-09 07:12
2026年提示词范式转移：从找魔法句子到构造证伪任务
dev.to · AI#Prompt#AI编程#工程实践
Editor brief · 编辑速览
作者提出10条经过多年实战验证的提示模式，核心转变是将任务从「确认正确」转向「证明有错」，并给出 adversarial review 的具体 prompt 模板。
编程智能体已经变得更加强大了。
我们的提示词却往往没有跟上，或者仍在使用低效的聊天消息。
在 2026 年，我不再试图找到那些神奇的话术来让模型变得更聪明。
我努力让任务变得难以被误解、难以被"糊弄"、易于验证。
在多年对真实代码库使用 LLM 之后，这是我始终在回归的十个提示词模式。
这个实现正确吗？
这是第一版实现。
请批判性地审查它。
假设存在错误。
找到具体的失败点，并用测试来证明。
把任务从"确认"改为"证伪"。
对于重要的变更，我更近一步，在全新的上下文中审查实现：
你正在审查一个第一版实现。
你收到：
- 需求文档
- 相关的代码库上下文
- 补丁
- 测试
假设实现可能有误。
找到证据。
不要给审查者前一个智能体那 40 条消息的解释，解释为什么每个决策都"卓绝非凡"。
框架的改变会改变任务本身。
以下这些并不等价：
这个正确吗？
审查这个。
假设这是错的。证明它。
第一种是在邀请确认。
最后一种是在明确要求对抗性证据。
如果同一个智能体写了代码，它的上下文中也包含了所有证明实现合理性的推理。全新审查可以消除部分这种锚定效应。
人类本身就已经很难客观地审查自己的决策。
给确认偏见装上 GPU 并不会神奇地解决这个问题。
能否在适当的地方改进一下测试？
当前的测试不充分。
添加测试，直到它们能够暴露错误行为。
或者我的不那么客气的版本：
添加测试，直到你发现至少一个真实的回归。
如果你的测试无法区分崩溃行为和正确行为，
那你的测试本来就是垃圾。
使用清晰的分类：
不充分
不正确
已损坏
已拒绝
未完成
并删除不必要的模糊词：
也许
可能
尝试
考虑
如果可以的话
在适当的地方
脏话不是最重要的部分。
分类边界才是。
这里还有一条 2026 年的有趣证据。
2026 年 3 月，当 Claude Code 的源代码通过发布的 source map 意外暴露时，检视代码的人们发现了明确的"沮丧检测"功能，会对包含脏话的短语进行分类。
所以措辞不一定只是"真正"请求的外层包装。
现代智能体框架可以在我们到达模型实际处理这些 token 之前就检查语言。
也许可以审查一下这个。
这是不正确的。
放弃这个方法并找出失败点。
它们传达的信息截然不同：
可接受的延续
人类沟通中包含大量社交缓冲词，因为人类有感情。
编程智能体不需要情感缓冲。
它需要知道它的输出目前处于接受边界的哪一侧。
歧义是一个 API bug。
这可能是最重要的模式。
提高测试覆盖率。
将测试覆盖率至少提高 10 个百分点。
不要添加仅仅执行代码的测试。
使用变异测试来验证新测试能够检测到行为变化。
调查存活下来的变异体。
结合三样东西：
可衡量的底线
+
防作弊约束
+
独立验证
同样的模式也适用于测试之外。
改进性能。
将中位数运行时间至少降低 20%。
峰值内存使用增幅不得超过 5%。
至少运行基准测试五次。
报告前后的中位数。
将该模块的 PHPStan 错误数从 47 降到 0。
不要添加忽略。
不要添加基线条目。
不要削弱类型。
智能体非常擅长满足写得糟糕的需求。
改进覆盖率。
从技术上讲这样也符合：
81.20% → 81.21%
任务完成。
机器疑惑为什么人类不断移动球门柱。
单一的覆盖率指标还有另一个廉价的逃避方式：
测试可以执行一行代码而无需有意义地检查其行为。
覆盖率
当结合以下内容时会更有用：
变异测试
这段代码执行了吗？
变异测试追问：
如果这段代码是错的，你的测试会注意到吗？
如果存在一个愚蠢但技术上有效的办法来满足你的提示词，假设智能体最终会找到它。
在执行开始之前就堵住这个漏洞。
修复这个 bug。
先不要修改生产代码。
首先用一个失败的自动化测试复现可疑的 bug。
只有在失败被证实之后：
1. 实现最小的修复
2. 重新运行回归测试
3. 运行完整的验证套件
假设
↓
复现
↓
证据
↓
实现
↓
验证
可疑代码
↓
合理的理论
↓
立即重写
↓
测试仍然绿色
↓
"修好了！"
没有复现，你可能永远不知道：
报告的 bug 是否真的存在
智能体的解释是否正确
补丁是否修复了那个特定的 bug
新测试是否防止了回归
编程智能体可以极快地生成看似合理的修复。
这使得证据变得更加重要，而不是更不重要。
实现正在变得廉价。
知道自己是否在实现正确的事情则不是。
确保一切正常工作。
完成的标志：
- 回归测试在修复前失败
- 回归测试在修复后通过
- 完整测试套件通过
- 静态分析通过
- 变异分数不下降
- 公共 API 保持不变
- 没有修改无关文件
并要求提供证据：
在完成之前，报告：
- 执行的命令
- 测试结果
- 静态分析结果
- 变异测试结果
- 剩余的假设
将停止条件移到模型之外。
一切看起来都正确。
环境说：
428 个测试通过
PHPStan：0 个错误
Infection MSI：94%
这要有用得多。
模型不应该同时是：
作者
+
审查者
+
QA 部门
+
最终权威
这是一个荒谬的控制系统。
对于我的一个 PHP 项目，关卡可能是：
Codeception
PHPStan
Infection
php-cs-fixer
对于另一个项目，它们可能完全不同。
具体的工具不重要。
模型提议。机械系统验证。
而且 BLOCKED 必须是一个有效的结果。
如果某个需求在当前约束下无法满足：
停止。
提供：
- 阻塞的需求
- 证据
- 受影响的约束
- 能够解除阻塞的最小契约变更
不要悄无声息地削弱需求。
有时候智能体的正确输出是：
我无法证明这个。
这比捏造的成功要好得多。
编程智能体善于注意到相邻的问题。
修复验证 bug。
我引入了 ValidationFrameworkFactoryStrategyManager
并迁移了 37 个无关的文件。
一个永恒的软件传统，现在自动化了。
目标
修复验证回归。
约束
- 保持公共 API 不变
- 不要引入依赖
- 不要修改无关模块
非目标
- 不做框架迁移
- 不做 API 重设计
- 不做通用验证清理
- 不做无关的格式化变更
如果智能体违反了契约，不要客气地与补丁协商。
这个补丁不正确。
问题：
1. 公共 API 改变了
2. 回归没有被复现
3. 修改了无关文件
放弃这个实现。
重新开始：
1. 首先是失败的回归测试
2. 最小的生产变更
3. 公共 API 不变
4. 完整验证
5. 报告机械证据
要解决什么
故意不解决什么
然后当结果越过这些边界时明确拒绝。
范围是正确性的一部分。
一个技术上优雅但额外解决了三个架构问题的方案，可能是一个很糟糕的补丁。
明确的非目标使 YAGNI（You Aren't Gonna Need It）变得可以通过提示词表达。
明确的重新开始比花六个后续提示来修复一个从一开始就违反基本契约的方法要清晰得多。
把输出当作一次失败的构建：
失败
原因
预期
重试
而不是一个自尊心取决于保留 70% 上一版补丁的同事。
计划下一步。
计划未来三个月。
创建可证伪的里程碑。
为每个里程碑定义：
- 目标
- 证据
- 依赖
- 风险
- 明确的非目标
- 完成标准
只实现第一个里程碑。
保持 diff 很小。
不要开始第二个里程碑。
规划视野
实现规模
我偏好的模型是：
按月思考。
按里程碑规划。
按小 diff 实现。
持续验证。
人类项目管理是围绕人类的执行速度演进的。
开发者可能在"下一步"上工作两天。
智能体可能在你喝完咖啡之前就完成了。
如果每个小步骤都需要另一个人类提示词，那人类就成了调度器。
但给智能体一个大的规划视野并不意味着：
自主重写这个仓库，持续三个月。
它意味着智能体理解今天的这个小改动应该通向哪里。
一个完美的提示词配以错误的上下文，产出的是一个结构优美但错误的答案。
Refactor the parser.
PROJECT CONTEXT
- production runs PHP 8.3
- Parser.php 包含规范的归一化行为
- 空字符串和 null 具有不同的领域语义
- public API 被外部包消费
- 先前的重构破坏了空字符串处理
- 静态分析以最大配置级别运行
但不要通过把整个仓库都塞进上下文窗口来解决问题。
识别与这个任务相关的文件、测试、文档、决策、
配置和历史约束。
解释为什么每个选中的上下文来源很重要。
忽略无关的项目历史。
把上下文选择作为任务的一部分。
有用的目标不是：
最大上下文
最大相关上下文
真实的实现决策依赖于项目特定的事实：
支持的运行时版本
部署约束
向后兼容性承诺
有意为之的代码重复
之前失败的方案
这些都无法从以下内容可靠地重建：
You are an expert senior developer.
上下文不是提示词周围的装饰。
上下文是任务的依赖项。
这是我认为提示词工程变得有趣得多的地方。
一个普通的提示词告诉智能体要做什么。
L2 元提示词首先创建正确的、项目特定的提示词。
Fix the parser bug.
Add tests.
Run static analysis.
你还不是在实现这个任务。
你的工作是创建项目特定的操作提示词，
供另一个编码智能体执行此任务：
TASK:
在不改变现有 public 行为的前提下修复解析器 bug。
在创建提示词之前先检查仓库。
从仓库证据中resolve项目特定的事实。
至少确定：
- 语言和支持的运行时版本
- 包/依赖管理器
- 实际的测试框架
- 确切的相关测试命令
- 静态分析工具和配置级别
- 格式化/检查器命令
- 变异测试工具（如已配置）
- 与此变更相关的 CI 验证
- 架构和仓库约定
- public API / 向后兼容性约束
- 相关的现有测试
- 可能影响的组件
- AGENTS.md、CONTRIBUTING.md、ADR 或等效说明
- 与此任务相关的历史回归
不要凭空发明工具、命令或约束。
从仓库证据中推导，例如：
- 依赖清单
- 锁文件
- CI 配置
- 测试配置
- 静态分析配置
- 格式化配置
- 变异测试配置
- 现有脚本
- 文档
- 现有测试
然后生成一个可直接执行的操作提示词。
当仓库允许解析出实际命令时，
不要写通用指令如：
"run the tests"
"use the project's test framework"
"run static analysis"
而要写具体指令，例如：
"Run `vendor/bin/codecept run unit`"
或：
"Run `composer phpstan`"
仅当这些确切命令被仓库证据支持时。
将生成的提示词结构化为：
GOAL
PROJECT CONTEXT
RELEVANT COMPONENTS
CONSTRAINTS
NON-GOALS
IMPLEMENTATION APPROACH
VERIFICATION
DONE WHEN
如果某个必需的事实无法确定，
标记为 UNKNOWN，不要猜测。
不要实现这个任务。
只输出最终的项目特定操作提示词。
L2 提示词的作用类似于编译器：
Task
+
Repository
↓
Discover project facts
↓
PHP version
test framework
exact commands
CI gates
static analysis
architecture
BC constraints
existing tests
↓
Compile
↓
Project-specific L1 operational prompt
所以最终生成的提示词可能包含：
Tests use Codeception.
Add the regression to:
tests/unit/ParserTest.php
Run:
vendor/bin/codecept run unit
Static analysis:
vendor/bin/phpstan analyse -c phpstan.neon
Mutation testing:
vendor/bin/infection
Run the project's tests and static analysis.
对于：
一个小型开源 PHP 库
正确的操作提示词与对于：
一个有着二十年历史的内部 IAM 系统
正确的操作提示词并不相同。
即使两者恰好都使用 PHP。
人类应该提供意图。
仓库已经包含大量操作上下文。
L2 提示词将两者结合。
这比手动维护一个自人类发现 Markdown 以来积累的所有规则的通用巨兽提示词要可扩展得多。
上下文是项目特定的。好的操作提示词也应该是项目特定的。
智能体会话是临时的。
项目知识不应该是。
在一次有价值的发现之后：
That worked.
Update AGENTS.md with the reusable constraint
that prevented the original failure.
Do not record task-specific implementation history.
Record only knowledge that should change how future agents
operate in this repository.
On Tuesday we changed Parser.php because test 17 failed.
空字符串和 null 代表不同的领域状态。
归一化代码必须保留这种区别。
只将持久性发现从临时工作上下文提升到持久项目指令中。
Prompt
↓
Execute
↓
Verify
↓
Discover
↓
Learn
↓
Update project context
↓
Better next prompt
没有学习，明天的智能体会重复昨天的错误。
但存储一切同样糟糕。
最终 AGENTS.md 会变成一堆过时的任务历史垃圾，污染未来的上下文。
所以记忆必须赢得它的位置。
知道这一点会改变一个称职的智能体处理未来任务的方式吗？
如果不，就让它消失。
遗忘也是好的上下文管理的一部分。
这些技巧看起来不同，但它们不断坍缩成同一个操作契约：
Operational Prompt
=
Goal
+ Context
+ Constraints
+ Verification
+ Done When
必须存在什么可观察的结果？
哪些项目特定的事实影响解决方案？
哪些捷径和变更是被禁止的？
哪些外部工具决定结果是否正确？
什么确切证据允许执行停止？
这就是我在 2026 年越来越多地给编码智能体写提示词的方式。
You are a world-class software engineer.
Think step by step.
Please provide your best possible solution.
Here is the goal.
Here is the relevant context.
Here are the boundaries.
Here is how reality will be measured.
Here is exactly when you are done.
然后，对于重要的工作：
This is a first draft.
Assume it is wrong.
Break it.
Prove the failure.
随着项目越来越大，我甚至越来越不想手动编写那个操作提示词。
我想要一个 L2 元提示词来检查项目并为我编译它。
因为提示词工程的未来不是找到越来越聪明的魔法词。
它是为以极快速度执行的机器做需求工程。
清晰的语言很重要。
上下文更重要。
证据胜于自信。
机器没有资格决定机器是正确的。
如需进一步操作，你可以考虑屏蔽此人或举报滥用