可能迄今为止最好的 Cursor RULE. 有状态、DDD(Document Driven Development)

G 老师的评价

在使用 AI 辅助编程工具时，我观察到其默认的交互模式在处理复杂工程任务时，存在两个主要挑战：

无状态交互 (Stateless Interaction)：AI 的大部分决策依赖于当前会话的上下文和已打开的文件。它缺乏对项目历史、架构决策和长期目标的持久化记忆，导致其建议可能在短期内有效，但长期来看会损害项目的一致性。

统一化的处理策略 (Uniform Processing Strategy)：无论是修复一个单行 bug 还是构建一个全新的复杂模块，AI 倾向于采用相似的交互和处理逻辑，缺乏根据任务风险和复杂度动态调整其工作流程的能力。

为了应对这些挑战，我设计了一套 Prompt 工作流，旨在将结构化的软件工程方法论注入到与 AI 的协作中。本文将主要介绍这套名为 THXAN-2 的 Prompt ，并分析其设计原则与优势。

该 Prompt 的核心目标，是让 AI 从一个“指令执行者”转变为一个“项目架构伙伴”。它通过以下几个核心设计原则来实现这一点：

1. 文档驱动的可预测性 (Doc-Driven Predictability) 机制：强制 AI 将项目根目录下的 .docs 文件夹视为“单一事实来源 (Single Source of Truth)”。所有重要的开发活动，如功能需求、技术方案、架构决策等，都必须先沉淀为文档。

技术优势：

提供持久化上下文：解决了 AI 的无状态问题。AI 在执行任何任务前，都会被引导去查阅相关文档，使其决策基于整个项目的历史和既定规范，而非临时的、不完整的上下文。

降低沟通模糊性：文档是人与 AI 之间最精确、无歧义的沟通语言。一个明确的技术方案文档（ TECH_DESIGNS/*.md ）远比几句自然语言描述更利于 AI 生成高质量、符合预期的代码。

1. 上下文自适应的工作流 (Context-Aware Workflow) 机制：引入“任务分流 (Task Triage)”模块。AI 在响应请求前，必须先对用户意图进行分类，并根据任务的类型和规模，选择不同的、预设的流程。

重大功能开发：遵循严格的五阶段流程（需求 -> 方案 -> 测试定义 -> 实现 -> 验收），强制进行充分的规划和验证。

代码维护或微小变更：采用轻量级的“快速通道”流程，在保证质量的前提下（先定义成功场景或简单测试），提升效率。

分析与调试：切换到以信息收集和逻辑推理为主的“问答模式”。

技术优势：

风险与效率的平衡：为不同风险等级的任务匹配了不同严格程度的流程，避免了“用牛刀杀鸡”的效率浪费，也防止了“轻率处理复杂问题”的质量风险。

流程标准化：使 AI 的行为模式变得高度可预测。你知道当你在处理一个复杂功能时，AI 一定会引导你先进行规划，这种确定性是高效协作的基础。

1. 默认开启的质量保证 (Quality Assurance by Default) 机制：将测试驱动开发（ TDD ）的理念作为核心原则。任何涉及逻辑变更的编码工作，都必须先于实现去定义一个或多个可执行的测试用例。

技术优势：

明确成功标准：迫使 AI （和用户）在写代码之前，就清晰地定义了“怎样才算完成”。这使得 AI 的目标函数非常明确，生成的代码质量更高。

保障代码回归：在持续的开发和重构中，积累的测试用例成为了保障系统稳定性的安全网。

对比分析：为何此模式更优？ 相较于默认的 AI 交互模式，thxan.md 工作流提供了几个关键优势：

从“无状态”到“有状态”：通过 .docs 目录，为 AI 提供了项目级的持久化记忆，使其决策更具全局观和一致性。

从“通用”到“专用”：通过任务分流，使 AI 的处理策略更具适应性，能根据具体场景应用最合适的工程实践。

从“不可测”到“可验证”：通过强制测试先行，将 AI 生成代码的正确性从一个主观感受问题，转变为一个可以通过测试报告客观衡量的标准.

https://github.com/thxan/THXAN-2

求 STAR

后续也会持续优化.