很多人以为，AI 效果不好，问题出在模型不够强、提示词写得不够细，或者上下文不够长。

但我越来越觉得，很多失败其实发生得更早。

不是发生在模型开始生成之后，甚至不是发生在提示词写完之后。

而是发生在执行开始之前。

换句话说，很多提示词的问题，不是“表达不够完整”，而是逻辑结构根本没有对齐。

---

一、一个很常见但很少被承认的事实

很多复杂请求，表面上看起来已经很清楚了。

比如：

• “帮我设计一个多 Agent 协作编程流程”
• “帮我设计一个审批流，支持驳回、重提和加签”
• “帮我写一个 Skill，在执行前先澄清复杂需求”
• “帮我做一个提示词框架，适用于多步骤业务逻辑”

这些需求都不模糊，甚至往往已经写得很详细。

问题在于：

详细，不等于结构闭合。

一个需求可以有很多细节，但依然没有回答这些更关键的问题：

• 这里到底有哪些实体？
• 谁是 source of truth？
• 哪些规则是不可破坏的？
• 当两个合理规则冲突时，谁优先？
• 中途失败时是回滚、保留、补偿，还是转人工？
• “成功”到底意味着什么？

这些问题如果没有在执行前被显式定义，那么模型开始生成得越快，往往只会更快地把一个未对齐的逻辑包装成一个看起来完整的产物。

这也是为什么很多提示词会出现一种很诡异的现象：

第一眼看，好像挺对。

第二眼看，发现很多地方没定义。

第三眼看，才意识到从一开始方向就偏了。

---

二、问题不在“提示词太短”，而在“执行开始得太早”

大家平时优化提示词，常见的方法通常是：

• 补充更多上下文
• 增加更明确的角色设定
• 规定输出格式
• 分步骤要求模型思考
• 给模型更多示例

这些方法都有效。

但它们默认了一个前提：

用户当前给出的需求，已经是一个可以进入执行阶段的需求。

而这件事，很多时候恰恰不成立。

很多复杂请求不是不能执行，而是不应该立刻执行。

因为它们缺少的不是词，而是结构。

比如你让模型设计一个多 Agent 工作流：

• writer 负责写代码
• reviewer 负责 review
• merger 负责合并

这听起来很合理。

但如果此时直接进入执行，模型很可能会立刻开始写流程图、写角色职责、写交互协议。

可真正致命的问题其实可能是：

• reviewer 一直否决怎么办？
• 谁拥有最终 merge 权限？
• review 结论是 advisory 还是 blocking？
• 如果 merge 通过了，但 post-merge validation 失败怎么办？
• 最低什么状态下才允许进入 merge？

这些问题不是“细化实现”的问题。

它们决定的是：

你设计的到底是一个能运行的系统，还是一个只在顺利路径上成立的幻觉。

---

三、我后来把这个问题总结成一句话

很多提示词失败，不是因为不会写，而是因为在逻辑还没对齐时就开始执行了。

这个判断对我影响很大。

因为它意味着，提示词优化不应该只发生在“怎么说”这一层。

还应该有一个更靠前的阶段：

在执行之前，先对齐逻辑。

这不是普通意义上的“澄清需求”。

也不是简单多问几个问题。

而是像系统设计一样，先把这件事的底层结构挖出来：

• 它到底由什么组成
• 哪些规则是铁律
• 当现实变脏、变乱、变中断时，它会怎样表现

于是我后来给这个过程起了一个名字：

Logic Architect

它本质上不是一个“更强的提示词模板”。

而是一个前置推理层：
在正式执行之前，强制需求暴露自己的隐藏假设和逻辑缺口。

---

四、我为什么使用了 M.E.N. 这个框架

我最后把这个前置推理层收敛成了一个三层框架，叫做 M.E.N.：

• M — Metadata
• E — Essence
• N — Non-linear

它不是为了显得抽象，而是为了逼自己和模型都去回答三类最容易被跳过的问题。

1）M — Metadata

这一层解决的是：

这个系统里到底“有什么”。

不是泛泛列对象，而是去建模：

• 有哪些实体
• 哪些是持久的，哪些是运行时状态
• 谁依赖谁
• 谁是 source of truth
• 结构关系是什么
• 某个上游变化后，下游是继承、重算，还是失效

很多需求的问题，不是没有功能，而是对象关系一开始就没立住。

2）E — Essence

这一层解决的是：

这个系统里什么必须永远成立。

也就是：

• invariants 是什么
• 成功到底怎么定义
• 规则冲突时谁优先
• 哪些 tradeoff 不能假装不存在

我越来越觉得，很多看起来“设计得差不多”的方案，真正拉开差距的往往不是功能项多少，而是这一层是否足够清楚。

3）N — Non-linear

这一层解决的是：

当事情不按顺序发生时，这个系统怎么活。

比如：

• 某一步失败了怎么办
• 中途打断怎么办
• 允许 partial completion 吗
• 可以 backtrack 吗
• 两个并行修改冲突时怎么处理
• 最低什么状态仍然算合法

现实世界的问题，最少是在线性 happy path 上出错，最多是在非线性状态里出错。

所以如果只会设计“顺利流程”，那基本等于没设计。

---

五、我越来越不相信“顺从型提示词”

我后来发现，真正高价值的提示词或者 Skill，不应该只是顺着用户往下写。

因为用户说得越完整，并不代表用户理解得越完整。

很多时候，用户只是把第一种实现形状说得很完整。

这两者是完全不同的。

所以 Logic Architect 的核心，不是“更会生成”。

而是：

在执行前，先挑战最危险的隐藏假设。

这里的挑战，不是为了抬杠，也不是为了显得自己聪明。

而是要精准打到那个最可能让整个方案失真的逻辑真空。

比如：

• 你以为自己定义的是 requirement，其实只是第一版 implementation shape
• 你以为 success 已经清楚了，其实只是 output 看起来完整
• 你以为流程支持回退，其实并没有定义历史继承语义
• 你以为并发能处理，其实只是没显式暴露冲突

我越来越相信：

好的 challenge，不是让用户不舒服。

而是让逻辑缺口无法继续伪装成“已经想清楚了”。

---

六、一个最简单的例子：多 Agent 编程流程

假设用户说：

设计一个 AI 编程流水线，一个 Agent 写代码，一个 Agent review，一个 Agent 自动 merge。

一个普通提示词，可能会立刻输出：

• Writer 负责编写代码
• Reviewer 负责代码审查
• Merger 负责合并分支
• 流程如下……

看上去很完整。

但如果先过一层 Logic Architect，它会先问：

• reviewer 无限否决时，谁打破僵局？
• merge 的最终授权归谁？
• review 结论是建议性的还是阻断性的？
• merge 前的最低合法状态是什么？
• 如果 merge 成功但验证失败，怎么补救？

然后再进入 M.E.N.：

M — Metadata

• 实体：writer、reviewer、merger、human operator、branch state、review state
• source of truth：review state + branch status
• topology：writer → reviewer → merger，但 human operator 拥有最终 override

E — Essence

• 未验证代码不得自动进入主分支
• human override 保留最终决策权
• merge 的合法性取决于 review 与 validation 的联合状态

N — Non-linear

• 连续 3 次 review 不通过，进入人工决策
• merge 后验证失败时，进入回滚或热修复路径
• 任一关键状态缺失时，不允许进入 merge

到这一步，执行才开始有意义。

因为现在你不是在“写一个看起来合理的流程”，而是在“实现一个已经被结构化过的系统”。

---

七、这件事对 Prompt Engineering 的意义是什么

我觉得它指向一个很重要的转变：

Prompt engineering 不应该只是一种表达优化技术。

它正在变成一种结构设计技术。

过去大家讨论提示词，重点经常是：

• 用什么角色设定
• 怎么给示例
• 怎么分步骤
• 怎么限制输出格式

这些当然都重要。

但在更复杂的任务里，真正决定上限的其实是：

你有没有在执行前，把逻辑结构压实。

也就是说，未来真正有价值的提示词能力，可能不只是“会写 prompt”。

而是：

• 会建模
• 会定 invariants
• 会识别 hidden assumptions
• 会设计 conflict hierarchy
• 会处理 rollback / partial / recovery

从这个角度说，Prompt Engineering 的下一阶段，更像是：

把系统设计、产品设计、协议设计的方法，前移到提示词之前。

---

八、为什么我把它做成了一个 Skill

我最后没有只把它写成一段 prompt。

因为我越来越明确地感受到：

Prompt 和 Skill 是两回事。

Prompt 更像一次性的执行指令。

Skill 则更像一个带有：

• 触发条件
• 生命周期
• 阶段协议
• 输出合同
• 确认与回退机制

的可复用前置逻辑层。

这也是为什么我最后把 Logic Architect 做成了一个独立 Skill。

它不是简单说一句：

你现在是一个逻辑架构师，请帮我分析。

而是明确规定：

• 什么情况下它应该触发
• 先 challenge 还是先建模
• 输出应该包含什么
• 什么情况下继续执行，什么情况下要确认
• 用户回改某一层时，应该局部更新还是整体重建

我更愿意把它理解成：

一个在正式生成前运行的小型 reasoning runtime。

---

九、我目前最认同的一句话

如果要用一句话概括这件事，我现在最认同的是：

很多糟糕执行，并不是始于糟糕生成，而是始于未被挑战的结构。

这句话对我来说比“怎么把提示词写得更长”重要得多。

因为它改变的是思考顺序。

不是先问：

• 我要怎么写，模型才会做得更好？

而是先问：

• 这个需求，真的已经配得上执行了吗？

---

十、最后

我不认为所有任务都需要 Logic Architect。

简单任务、低风险任务、试错成本极低的任务，完全没必要先做一轮逻辑预审。

但只要任务开始涉及：

• 多实体关系
• 状态迁移
• 冲突优先级
• 回退 / 中断 / partial completion
• 下游实现成本较高

那么“先执行再修”通常都不是最优策略。

因为你修掉的，往往只是表层输出；
真正的问题仍然埋在结构里。

所以我现在越来越愿意把这件事说得更直接一点：

不是所有复杂提示词都需要更长。

很多复杂提示词真正需要的，是在执行开始前，先被迫诚实。

而 Logic Architect，只是我为这种“被迫诚实”写下的一种形式化方法。

---

项目地址

如果你对这个方向有兴趣，我把这个Skill整理成了一个开源项目：

• GitHub: https://github.com/hqy2435662352/logic-architect

项目里包含：

• SKILL.md：完整 Skill 规范
• README.md / README.zh-CN.md：中英文说明
• examples/：示例场景
• M.E.N. 框架与执行交接层

如果你也遇到过“提示词看起来没问题，但一执行就发现逻辑没对齐”的情况，欢迎交流。