从与 AI 聊天到为其架构设计

Source: Dev.to

为什么我不再只提示代码，而是把 AI 当作一个系统来对待

我们都有过这种经历。

你让 AI 编码助手构建一个简单的组件。
代码瞬间生成，看起来很干净，运行也没有错误。

但随后你仔细检查：

• 它引入了我们不使用的新图标库。
• 它忽略了项目严格的文件夹结构。
• 它硬编码了 20px 的内边距，而不是使用设计系统的间距尺度。

接下来通常是一轮又一轮的来回：微调模型、重构输出、纠正架构漂移。

某个时刻，我意识到问题不在代码质量，而在 上下文。

AI 的表现更像是一个刚加入团队的高能初级开发者：它懂语法，却不了解本地约定、限制或意图。大多数修复尝试都集中在“更好的提示”。对我而言，更有效的做法是一次结构性的转变：把 AI 交互视为系统设计问题。

构建 AI “操作系统”

我不再把 AI 当作对话工具，而是把它当作可编程引擎。在仓库内部，我逐步引入了一套基于文件的结构，用来管理 AI 在不同任务中的行为。它并不试图自行变得智能；而是显式加载上下文。一些协议始终可用，另一些仅在能提供明确价值时才加载——主要通过 @plan 或 @deep-think。随着时间推移，这演变成一个一致的工作模型。

1. 交换机：单一入口点

大型系统提示难以扩展；随着规则累积，行为变得难以推理。与其不断添加指令，我重新利用了 copilot-instructions.md——工具提供的约定文件——作为路由层。它的功能相当于交换机：指向规则，而不是直接包含规则。

示例路由逻辑

If the user types `@plan`, load the Architecture Guidelines.
If they type `@ui-perfect`, load the Design System rules.
If they type `@test`, load the QA protocols.

较小的提示保持轻量，而复杂任务则显式加载额外上下文。这种分离显著降低了不可预测的行为。

2. 深度思考作为决策步骤

直接让 AI 给出解决方案往往会产生常规或通用的模式。对于涉及权衡的任务，我使用专门的步骤：@deep-think。

在此模式下，模型必须：

1. 从系统层面审视问题。
2. 提出多种方案。
3. 明确风险和约束。

为结构化这种推理，我使用了一个简单的红黄绿灯评估标准：

• 🔴 BLOCKER — 与约束冲突或引入明显风险
• 🟡 WARNING — 可行，但存在显著权衡
• 🟢 OPTIMAL — 对齐、可维护且与系统一致

价值不在于标签本身，而在于实现前必须为决策提供理由。此步骤的关键部分是 “先搜索再构建”：模型会扫描现有代码库，寻找模式、工具函数和已有实现，从而持续降低重复和分歧。

3. 治理作为可选层

对于较大或长期特性，我有时会引入显式的治理文件：

• 架构边界
• 代码风格约束
• 已知反模式

这些文件主要用于锚定 AI 行为，而非面向人类的文档。它们是自愿启用的；对于小型或探索性工作，我常常直接跳过。目标是获得可衡量的杠杆效应，而不是增加程序性负担。

4. 将规划与执行分离

另一个被证实有效的调整是把设计与实现分开。与其让 AI 同时进行计划和构建，我把流程拆分。

@plan

此步骤生成 PLAN.md 文档，内容包括：

• 受影响的文件
• 高层数据流
• 模块边界和契约
• 测试考虑

不生成代码。计划可以独立审查和调整。

@build

仅在计划被接受后才运行 @build。此时 AI 将计划视为规范并直接实现。这种分离减少了意外的结构性更改。

5. 处理 UI 精度

在没有指导的情况下，AI 的视觉输出仍然不可靠。当 UI 细节至关重要时，我使用专门的 @ui-perfect 步骤。流程非常直接：

1. 分析 设计中的布局和间距。
2. 映射 测量值到设计系统的 token。
3. 实现 前先进行归一化。

此步骤并非通用，但在需要精确时，将分析与实现分离能产生更一致的结果。

6. 典型流程

标准特性工作流现在如下：

1. 运行 @plan
2. 审查并完善 PLAN.md
3. 运行 @build
4. 验证行为
5. 如需视觉精度，运行 @ui-perfect
6. 运行 @extract-concerns
7. 运行 @test

流程本身并不复杂；改变的是可预测性。

结果

这种方法并没有消除判断的需求。它改变的是判断的施加位置。我们不再在事后纠正输出，而是提前投入精力定义生成输出的上下文。

这并非通用处方——仅是我个人形成的工作方式，以及它让 AI 输出符合生产期望的关键。