Architecture / Design Patterns / AI Coding / Prompt Architecture
架构设计才是当下程序员的核心竞争力
AI 可以越来越快地写出第一版代码，但它不会自动替你判断边界、变化点、依赖关系和长期维护成本。今天真正拉开程序员差距的，不是“谁敲得更快”，而是谁能把混乱需求组织成稳定结构，把一次性实现变成可验证、可演化、可协作的系统。
一、先说人话：为什么这件事现在更重要
过去，一个程序员的优势很大一部分来自“能不能把代码写出来”。现在，AI 已经能很快生成大量代码。问题变了：代码不再稀缺，稀缺的是判断。你要能判断这段代码该放在哪里、该不该抽象、接口该怎么切、状态该由谁负责、错误怎么恢复、未来改需求时会不会牵一发动全身。
AI Coding 把实现速度拉高了，也把结构失控的速度拉高了。以前一个坏设计可能慢慢腐烂，现在模型可以在几分钟内把同一种坏结构复制到十几个文件里。表面上项目进展很快，实际上后面每次改动都越来越痛。
二、设计模式到底是什么
设计模式不是“看起来很高级的类图”，也不是面试时背的标准答案。更通俗地说，设计模式是一批老程序员反复踩坑后总结出来的“变化处理套路”。它们解决的不是“这一行代码怎么写”，而是“这个地方以后经常变，怎么让它变的时候别把系统拖垮”。
比如价格计算规则经常变，就不要把所有折扣分支塞进一个大函数里，可以用 Strategy 把不同算法拆出来。第三方接口长得和我们系统不一样，就不要强行改全系统，可以用 Adapter 做一层翻译。主流程完成后有很多附加动作，就不要让主流程认识所有下游，可以用 Observer 只发布事件。
| 常见误解 | 更准确的理解 |
|---|---|
| 设计模式是固定模板 | 设计模式是对常见变化结构的命名，重点是意图，不是照抄代码。 |
| 模式越多越专业 | 只有真实变化点值得引入模式；没有变化点时，简单代码通常更好。 |
| 学模式是为了写复杂代码 | 学模式是为了知道什么时候该隔离复杂度，什么时候该克制。 |
三、架构设计到底是什么
架构设计不是 PPT 里画几个方框，也不是给项目加很多层。架构设计是对系统重要决策的安排：模块边界怎么划，数据从哪里来，状态归谁管，依赖朝哪个方向走，失败时怎么恢复，哪些地方允许变化，哪些地方必须稳定。
可以把架构理解成一座城市的道路、管线和分区。单个函数像一间房，设计模式像常见房型或连接方式，架构则决定整座城市怎么运行。如果主干道规划错了，再漂亮的房间也会堵成一团。
边界
哪些职责应该放一起，哪些必须分开。边界清楚，修改才不会乱扩散。
依赖
谁依赖谁，谁不能知道谁。依赖方向错了，系统会越来越难测、难改。
演化
需求变化时，系统是局部替换，还是全局震动。架构要为真实变化留出空间。
四、设计模式和架构设计是什么关系
设计模式更偏局部，架构设计更偏全局。模式像一把把工具，架构像决定什么时候用哪把工具、为什么用、用完后系统整体是否更稳的判断过程。
| 维度 | 设计模式 | 架构设计 |
|---|---|---|
| 关注范围 | 局部结构，例如对象创建、算法替换、接口适配。 | 全局结构，例如模块边界、数据流、部署形态、演化路径。 |
| 核心问题 | 某个变化点如何被隔离。 | 整个系统如何长期保持可维护。 |
| 常见失败 | 为了套模式而套模式。 | 只画概念图，不处理真实依赖和验证。 |
| 正确姿势 | 先看变化，再选模式。 | 先定边界，再组织实现。 |
好的架构不是把系统变复杂，而是让复杂度有地方待；好的设计模式不是增加抽象，而是让变化不要污染主干。
五、为什么 AI Coding 让架构能力更值钱
AI 很擅长根据眼前上下文补代码，但它不天然理解你的组织边界、历史包袱、线上风险和团队维护成本。它会倾向于把当前需求做出来，而不是主动追问“这个变化以后还会不会来”“这段逻辑是不是该独立测试”“这个状态是不是不该放在全局”。
所以 AI 时代的程序员，不应该退化成“提示词操作员”。更合理的定位是架构裁判和工程导演：你负责定义边界、目标、验收、风险和验证顺序；AI 在这些约束里做局部实现搜索。
六、提示词架构设计：Prompt 也不是随便写一句话
很多人以为提示词工程就是“把话说得更清楚”。这只是第一层。真正进入工程场景以后，Prompt 应该被看成一个推理接口。接口就要有输入、输出、约束、上下文和错误处理边界。
一个可控的 Prompt，至少要回答七件事：模型现在扮演什么自然角色，要完成的唯一主目标是什么，应该执行哪些动作，不能越过哪些边界，依据哪些背景材料，本轮输入是什么，最后必须输出什么格式。
| 字段 | 通俗解释 |
|---|---|
Role |
模型现在应该像谁一样工作，例如资深代码审查者、架构顾问、文档编辑。 |
Objective |
这次只有一个主目标，避免把多个阶段混成一团。 |
Instruction |
要做哪些动作，例如阅读、比较、提取、生成、检查。 |
Constraint |
不能做什么，例如不能改文件、不能编造验证结果、不能越权访问。 |
Context |
背景材料和已知事实，帮助模型理解环境。 |
Input |
本轮真正要处理的对象，应该和背景分开。 |
Output |
输出结构、语言、格式和示例，方便人或程序检查。 |
这就是提示词架构设计。它不是让 Prompt 变长，而是让 Prompt 像接口一样清楚。接口越清楚，模型越不容易乱跑，后续检查和重试也更容易做。
七、Harness：Prompt 管一轮推理，系统管整个流程
单靠 Prompt 不能构成可靠系统。Prompt 只能告诉模型“这一轮怎么回答”，但它不能天然负责状态保存、失败重试、上下文裁剪、测试执行、权限控制和结果验收。这些事情应该由外部 Harness，也就是围绕模型的一层工程壳来管理。
换句话说，LLM 是一个强推理模块，但不应该直接当系统大脑。真正的大脑应该是流程、状态机、检查器和验证机制。模型负责局部生成，Harness 负责让整个过程有秩序。
人类负责目标、边界和裁决
人要说清楚什么是成功，什么明确不做，风险在哪里，验收标准是什么。越是重要任务，越不能把裁决权完全交给模型。
AI 负责在约束内搜索实现
AI 适合做局部分析、生成、补全、对比和总结。它可以很强，但它的输出必须被检查，不能把“模型说了”当成完成。
Harness 负责流程秩序
Harness 负责拆阶段、装上下文、运行验证、失败重试、记录中间态和控制权限。没有 Harness，复杂 AI Coding 很容易退化成靠运气聊天。
八、程序员真正要练的五种架构能力
变化点识别
能看出哪些需求只是一次性改动，哪些会反复变化。看不见变化点，就谈不上设计。
边界感
知道哪些逻辑应该靠近，哪些逻辑必须隔离。边界感差，项目会越写越黏。
抽象克制
知道什么时候不该抽象。不成熟的架构常常不是太简单，而是过早复杂。
验证设计
能把“看起来对”变成“可以证明对”。没有验证协议，架构讨论很容易空转。
上下文组织
会给人和 AI 提供刚好够用的信息，而不是把所有材料一股脑塞进去。
演化判断
能判断当前设计在下一次需求变化时是局部替换，还是全局返工。
十、最后收束：当代码不再稀缺，结构就是护城河
AI Coding 的终点，不是程序员不用懂工程了，而是程序员更需要懂工程。因为 AI 让实现变快，也让错误结构扩散变快。未来真正有价值的程序员，不只是能写代码的人，而是能让人、AI、代码、测试、流程和文档协同工作的人。
设计模式训练局部结构判断，架构设计训练全局复杂度治理，提示词架构训练 AI 推理接口设计，Harness 训练任务生命周期控制。把这几件事连起来，就是当下程序员最值得投入的核心竞争力。
一句话总结：AI 负责加速产出，人类负责守住结构。谁能守住结构，谁就能在 AI 时代继续掌握软件工程的主动权。
参考文献
[1] Vortezwohl. AI Coding 完整方法论：从让模型写代码，到建立受约束的工程协作系统.
[2] Vortezwohl. AI Coding 时代，理解设计模式变得更加重要.
[3] Vortezwohl. 基于 Prompt4Py 的结构化提示词设计方法论.
[4] Vortezwohl. AGENTS.md：面向 AI Coding 的基础工程协作规约.
[5] OpenAI Research Team. Harness engineering: leveraging Codex in an agent-first world.
[6] Anthropic. Effective harnesses for long-running agents.
[7] Birgitta Böckeler. Context Engineering for Coding Agents. Martin Fowler.
[8] Refactoring.Guru. Design Patterns.
[9] Martin Fowler. Software Architecture Guide.
[10] Carnegie Mellon University Software Engineering Institute. What Is Software Architecture?.