AI代码编辑器 - AI代码框架 - AIdevflow的设计心得 - 以规矩为锚，让 AI 与工程同频

没有规矩不成方圆：把 AI 写作嵌入工程的心法

干货

规则即提示词

• 我把所有规则文件当作“个人 AI 代码编辑器的 Agent 提示词库”。它们不是旁注，是约束与能力的合约载体；引用它们，等于给模型明确边界与统一风格。
• 提示词不求“越长越好”，而求“规则化、组合化、可验证”。我以 project_rules.md 和 ai_rules_and_prompts.md 为主合约，再按需拼接领域规范与流程提示词，避免散乱。
• 我把工程规范直接“嵌入提示词”，而不是事后救火：分层职责、事务边界、装配（MapStruct）、返回值约束、日志与命名统一，系统性引用 engineering_standards.md 与 ddd_design_guide.md。
• 我把“噪音识别策略”也前置到提示词：禁止反引号路径，必须显式链接；拒绝编造文件/接口；输出必须对齐调用链。这些约束来自 noise_rules.md 与 model_routing_guide.md。
• 验收标准写在提示词里而非心里：测试分层、接口校验、事务与事件发布时机、提交信息格式等，用 testing_rules.md、api_test_rules.md、commit_and_release_rules.md 明确“何为合格产出”。
• 提示词要“活”，不是一次性：规则更新同步到 standard_prompts.md，并按 prompts_index.md 管理分类入口；变更与经验沉淀到 change_and_docs.md 与 ai_devflow_journal.md，并在 meta_index.md 保持可检索。
• 在多模型场景下，我让“路由策略也成为提示词的一部分”：不同任务选不同模型，但都走同一套规则引用与验收标准，避免风格漂移与无边界感输出（参考 model_routing_guide.md）。

实操心得

• 我把提示词拆成“三层”：主合约（统一边界与风格）、任务说明（具体目标与输入输出）、验收清单（测试/事务/提交/链接规范）。这样每次调用都可重用与快速审查。
• 任何生成前，我先链接到对应规则文档，再描述任务；生成后，我按规则做“静态审查”，不通过就回退到提示词修正规则引用，而不是在结果里东修西补。
• 生成不合规的常见根因，不是模型弱，而是提示词少了“工程约束”。我一旦发现幻觉或噪音，就立刻强化对应规则引用，尤其是分层、事务后事件发布、显式链接与装配规范。
• 我不追求“一次就对”，而是追求“每次都更对”：靠索引与日志缩短学习曲线，让提示词随项目演进；把失败案例写进标准提示词，下一次同类问题直接规避。
• 最明显的收益是“同频”：当规则即提示词、提示词即合约，模型的产出不再是拙劣模仿，而是稳定的工程增量；效率提升来自减少返工与审查成本，而不是靠“更长的输入”。

我的迭代闭环：一次需求的全流程（无代码叙事）

• 我提出一个清晰的需求，先引用主合约和工程规范，写好边界与验收标准。
• 我通过模型路由选择合适的模型，并在提示词里前置规则清单。
• 模型给出首稿，我用“幻觉与噪音对照表”快速审查，标记所有不合规点。
• 我不在结果上“救火”，而是回到提示词，补充边界与规范项，再次生成。
• 我把事务边界移到门面层、事件改为事务提交后发布、返回值统一、装配走 MapStruct。
• 我从最小变更点起测，再跑接口测试与脚本检查，确认没有结构性违规。
• 我按提交规范记录变更，并把经验写入开发日志与索引，方便下一次直接复用。

正文

第一次把 AI 代码编辑器引入到严肃工程流里，我很快意识到一个朴素却关键的事实：没有规矩不成方圆。这句话不是鸡汤，它是我在 AIDevflow 基座下高效使用 AI 的第一原则。我的目标从来不是让 AI“替我写代码”，而是让它在工程规则的框架内“为我加速”。这要求我把模型能力嵌入既有的工程规范、流程、边界与验收标准之中，让它成为增量，而不是变量。

我把主入口与主合约作为整个过程的唯一起点：project_rules.md 与 ai_rules_and_prompts.md。它们告诉我：规则先行，能力后置；约束是为了效率；边界是为了协作。这是我写下这篇文章的根基。

第一次输入到首次产出：直觉、惊喜与隐忧

我的第一次尝试很简单：给 AI 一个清楚的需求描述，模型很快给出“能看、能跑”的初稿。直觉上这是惊喜，但几分钟后隐忧就冒出来了。结果看似正确，却在工程维度上问题频出：分层越界、命名漂移、事务边界模糊、日志不合规、装配随意、返回值不统一、引用路径不规范。这些并不是语法问题，而是工程一致性与可维护性的硬伤。

我做的第一件事，不是“让它再改一版”，而是拿规范对照它的输出。我的“首轮审查清单”来自合并版工程规范与设计规范：engineering_standards.md 与 ddd_design_guide.md。我只看四件事：正确性、边界感、风格一致性、可维护性。只要这四件事过不了，哪怕代码能跑，也不会进入下一步。

幻觉与噪音：我如何识别与压降

所谓“幻觉”，在工程场景下的表现非常具体：模型编造不存在的接口或文件、绕开门面层直接调用仓储、擅自增加未声明的规则或枚举；所谓“噪音”，则是风格层面的漂移：命名不统一、日志英文或无上下文、字段注入、返回值随意、装配不走 MapStruct、引用路径用反引号而不是显式链接。这些现象在我看来，是“工程化的红线”。

我用一张“规则对照表”来快速识别问题根因，核心来自：noise_rules.md。它给了我一套清晰的界定方法：什么是幻觉、什么是噪音、什么是结构性违规（比如分层与事务边界），什么是可视化违规（比如链接引用风格）。我把它当作“审稿标准”，每次产出都先用它筛一遍，再决定是否进入迭代。

我如何纠偏：把规则前置到提示词，而不是事后救火

早期我常犯一个错误：拿到不合规的结果后再去一点点纠偏。这种事后救火成本极高。我后来改为“前置规则”：在与模型交互的提示词中明确写下分层职责、事务边界、装配规范、返回值约定、日志与命名要求、显式链接引用，以及关键镜头内的验收标准。这套做法的依据来自：standard_prompts.md 与 prompts_index.md。

我在提示词里明确写下调用链：Controller → Facade → Service → Repository/Dao；把事务边界放在门面层（读用例只读、写用例回滚边界），把领域事件设定为“事务提交后发布”；返回值统一用 DTO/VO 或结果包装类；装配统一走 MapStruct 并做字段映射文档；日志中文且上下文清晰；依赖注入统一构造器注入；禁止反引号路径，统一显式链接。这些都来自工程规范：engineering_standards.md。

当规则被“植入提示词”，模型产出会明显收敛。它不再是拙劣模仿，而是遵循统一项目风格的可靠增量。

索引驱动而非逐篇通读：把“找得到”变成“用得上”

在写作与迭代中，我不逐篇通读规则文件，而是先走索引：meta_index.md。这能让我快速定位“应该引用谁”。我按“合并版规范优先”的方法定位核心规则：工程规范、测试规范、提交与发布规范分别在 engineering_standards.md、testing_rules.md 与 commit_and_release_rules.md。

操作路径与协作机制，我看 dev_flow.md 与 tech_stack.md。变更与文档管理，用 change_and_docs.md。经验沉淀，我写在 ai_devflow_journal.md。这让规则不是“堆在一起的文件”，而是我每天都能用上的工具。

模型选择与路由：降噪的第一性变量

我很早就发现，噪音比与迭代成本与模型路由直接相关。我把“严谨任务”（分层、事务、装配、规范对齐）与“创意任务”（命名、文案、接口描述、用户体验）分开用不同模型，并在路由策略里为严谨任务增加规则约束。这也是我降低噪音比的关键手段。策略与方法参照：model_routing_guide.md 与 ai_interaction_guide.md。

我还建立“失败回退策略”：当某次产出明显不合规时，我立即回退到上一个合规版本，重新路由、重置提示词，避免不合规输出污染代码库。

分层与边界：门面层是我的“秩序之锚”

我把门面层（Facade）当作用例编排与事务控制的唯一入口，统一在门面获取登录用户信息，再传给领域服务层。这避免了 Service 直接获取登录态，保持边界清晰，协作顺畅。职责分离的细则与禁止事项都写在：ddd_design_guide.md。

我特别重视“事件发布时机”：只有在事务提交后才发布领域事件，这让状态一致性可控，也避免半成品泄露到外部系统。复杂查询统一使用原生 SQL + SqlBuilder 或 JPA Specification，禁止字符串拼接。装配统一走 MapStruct，并维护字段映射文档，杜绝“口口相传”的临时约定。这些都在工程规范里有清晰要求：engineering_standards.md。

质量保障与测试闭环：从最小变更点起步

我做任何迭代，都先从最小变更点起测，再逐步扩展到集成与接口测试。测试分层的做法与优先级，在 testing_rules.md 有明确建议；接口测试的策略与组织，我参考 api_test_rules.md。这让我避免“大而全”的浪费，把精力放在“确实可能出错的地方”。

在自动化层面，我把脚本融入日常：架构规则检查、事务注解检查、依赖注入规范检查、文档与规则链接校验，分别在脚本目录里都有现成工具（见项目根目录的 scripts/）。我坚持“失败即停、定位、回归”，而不是“先把东西跑起来再说”。发布节奏与提交风格，我严格遵循 commit_and_release_rules.md 与 git_commit_standards.md，并在适当场景采用 auto_commit_rules.md。这让协作信息可读、可追溯、可复用。

插件架构：可插拔能力也要受约束

当我需要扩展功能，我优先考虑插件化，而不是向核心模块“打洞”。插件的生命周期、注入约束、执行规则都在 aidevflow_plugin_architecture.md。我遵循“功能经 Facade 契约暴露”的原则，避免直连内部模块。共享服务（字典、评分、装配器）我尽量复用，避免重复建设。这些约束让我在扩展时也能保持工程一致性。

这一整套闭环，让我的迭代越来越稳、越来越快。

常见坑位与我的对策

• 未引用主合约，提示词发散 → 统一从 ai_rules_and_prompts.md 开始。
• Controller 直连 Repository → 强制经 Facade，守住分层边界。
• 事务与事件时机错误 → 只在事务提交后发布事件，避免状态不一致。
• 命名不统一、装配文档缺失 → 建立 MapStruct 映射文档与审查习惯。
• 只读用例忘记只读事务 → 按读写用例区分事务属性，门面层统一。
• 规则文件未显式链接 → 所有规则引用用显式链接，禁止反引号路径。
• 把纠偏放在事后 → 把规则前置到提示词，减少无效迭代。

总结：以规矩为锚，让 AI 与工程同频

我使用 AI 代码编辑器的心得可以归结为一句话：以规矩为锚，让 AI 与工程同频。当规则前置、边界清晰、验收明确、索引顺手、路由合理，AI 的产出就会从“拙劣模仿”变成“可靠增量”。我不会指望它替我做决策，但我会让它在我设定的工程轨道上高效跑起来。

写这篇文章的目的，不是夸大模型的能力，而是强调工程的底层秩序。我相信：只要把规则、索引、路由、提示词、测试与提交这些要素串成一套稳定的闭环，AI 的价值就会持续累积；噪音比会降、协作成本会减、学习曲线会压缩。最终，AI 不再是一个“外来者”，而是我们工程团队的一部分。