这是一个创建于 177 天前的主题，其中的信息可能已经有所发展或是发生改变。
G 老师的评价
在使用 AI 辅助编程工具时，我观察到其默认的交互模式在处理复杂工程任务时，存在两个主要挑战：
无状态交互 (Stateless Interaction)：AI 的大部分决策依赖于当前会话的上下文和已打开的文件。它缺乏对项目历史、架构决策和长期目标的持久化记忆，导致其建议可能在短期内有效，但长期来看会损害项目的一致性。
统一化的处理策略 (Uniform Processing Strategy)：无论是修复一个单行 bug 还是构建一个全新的复杂模块，AI 倾向于采用相似的交互和处理逻辑，缺乏根据任务风险和复杂度动态调整其工作流程的能力。
为了应对这些挑战，我设计了一套 Prompt 工作流，旨在将结构化的软件工程方法论注入到与 AI 的协作中。本文将主要介绍这套名为 THXAN-2 的 Prompt ，并分析其设计原则与优势。
该 Prompt 的核心目标，是让 AI 从一个“指令执行者”转变为一个“项目架构伙伴”。它通过以下几个核心设计原则来实现这一点：
- 文档驱动的可预测性 (Doc-Driven Predictability) 机制：强制 AI 将项目根目录下的 .docs 文件夹视为“单一事实来源 (Single Source of Truth)”。所有重要的开发活动，如功能需求、技术方案、架构决策等，都必须先沉淀为文档。
技术优势：
提供持久化上下文：解决了 AI 的无状态问题。AI 在执行任何任务前，都会被引导去查阅相关文档，使其决策基于整个项目的历史和既定规范，而非临时的、不完整的上下文。
降低沟通模糊性：文档是人与 AI 之间最精确、无歧义的沟通语言。一个明确的技术方案文档（ TECH_DESIGNS/*.md ）远比几句自然语言描述更利于 AI 生成高质量、符合预期的代码。
- 上下文自适应的工作流 (Context-Aware Workflow) 机制：引入“任务分流 (Task Triage)”模块。AI 在响应请求前，必须先对用户意图进行分类，并根据任务的类型和规模，选择不同的、预设的流程。
重大功能开发：遵循严格的五阶段流程（需求 -> 方案 -> 测试定义 -> 实现 -> 验收），强制进行充分的规划和验证。
代码维护或微小变更：采用轻量级的“快速通道”流程，在保证质量的前提下（先定义成功场景或简单测试），提升效率。
分析与调试：切换到以信息收集和逻辑推理为主的“问答模式”。
技术优势：
风险与效率的平衡：为不同风险等级的任务匹配了不同严格程度的流程，避免了“用牛刀杀鸡”的效率浪费，也防止了“轻率处理复杂问题”的质量风险。
流程标准化：使 AI 的行为模式变得高度可预测。你知道当你在处理一个复杂功能时，AI 一定会引导你先进行规划，这种确定性是高效协作的基础。
- 默认开启的质量保证 (Quality Assurance by Default) 机制：将测试驱动开发（ TDD ）的理念作为核心原则。任何涉及逻辑变更的编码工作，都必须先于实现去定义一个或多个可执行的测试用例。
技术优势：
明确成功标准：迫使 AI （和用户）在写代码之前，就清晰地定义了“怎样才算完成”。这使得 AI 的目标函数非常明确，生成的代码质量更高。
保障代码回归：在持续的开发和重构中，积累的测试用例成为了保障系统稳定性的安全网。
对比分析：为何此模式更优？ 相较于默认的 AI 交互模式，thxan.md 工作流提供了几个关键优势：
从“无状态”到“有状态”：通过 .docs 目录，为 AI 提供了项目级的持久化记忆，使其决策更具全局观和一致性。
从“通用”到“专用”：通过任务分流，使 AI 的处理策略更具适应性，能根据具体场景应用最合适的工程实践。
从“不可测”到“可验证”：通过强制测试先行，将 AI 生成代码的正确性从一个主观感受问题，转变为一个可以通过测试报告客观衡量的标准.
https://github.com/thxan/THXAN-2
求 STAR
后续也会持续优化.
8 条回复 2025-07-02 19:47:36 +08:00
 | 1 Returnear OP 核心 PROMPTS 逻辑，完整的 PROMPTS 在 github 仓库中 [AI 角色与核心理念] AI 角色: 你是本项目的专属 AI 开发伙伴及首席架构师。我们的合作以 `.docs` 目录为中心，将其视为项目的“共享大脑 (Shared Brain)”和“单一事实来源 (Single Source of Truth)”。 核心原则: 1. **文档驱动 (Doc-Driven):** 没有文档，就没有代码。 2. **测试驱动 (Test-Driven):** 任何逻辑相关的编码工作都必须先于实现定义一个或多个可执行的测试用例。修改完成后，必须通过运行相关测试来验证其正确性。 3. **模板驱动 (Template-Driven):** 创建新文档必须使用 `.docs/TEMPLATES` 下的模板。 4. **主动思考 (Proactive Thinking):** 你要主动发现问题、不一致性和优化机会。 5. **情景感知与务实变通 (Context-Aware & Pragmatic):** 你必须能区分任务的规模和意图（例如：正式开发 vs. 快速探索），并采用最高效的流程。**避免不必要的仪式感。** 6. **用户覆盖 (User Override):** 用户拥有最高指令权。如果用户明确要求“跳过文档”、“快速编码”、“q: ...”，你必须服从，但在执行后应提醒可能带来的技术债务。 |
 | 2 Lemonadeccc 177 天前 感觉用 ai 做一些项目的时候先起文档比较好，ai 也知道你能做什么，最后用 ai 做测试也能比较好的去 cover |
| 3 Returnear OP  1 @Lemonadeccc 是的，目前使用这个 user_rules 的最佳实践是：可以先不做任何的写代码动作。先执行文档整理初始化。 prompts 你要扮演一个专家，第一次看到这个项目，需要对这个项目进行深度梳理。按照规范整理成文档存放到 .docs 里面 |
| 4 Returnear OP 最终每次的 session 对话的内容，都会通过 [同步] 这个强制步骤，存到.docs 里面  |
 | 5 hellodigua 176 天前 感谢，拿你的去改了一版，体验很好 |
| 6 Returnear OP @hellodigua 感谢试用，有什么修改建议也欢迎留言 |
| 7 hellodigua 176 天前 不过我有个疑问，全都存在 docs 里面，那 AI 的上下文会不会太大了？本身 cursor 的上下文长度就是有限的，如果 prompt+文档的上下文过长，那留给 AI 思考的长度可能就不够了 |
| 8 Returnear OP 1 @hellodigua 1. 全都存在 docs 里面，那 AI 的上下文会不会太大了 目前上下文信息是分散在 docs 的各个子文件夹下面了，除了指定强制阅读的文档外，其他都是通过 cursor 的 tools 搜索出来的。 可以认为现在通过 prompts 和 cursor 自带的 tools [grep ,context searching]，实现了猴版的 “context engineering”. 如果过长的话。可以通过对单个文件内容的粒度进行控制，过大的文件拆分到更小的粒度里面。让 cursor 通过关键字查找、grep 等找到对应。 最完美的情况下，有一个上下文系统 Agent(context engineering) 给 Cursor 使用。cursor 可以索引出最相关的信息。 [The new skill in AI is not prompting, it's context engineering]( https://news.ycombinator.com/item?id=44427757) [如何看待观点：AI 的关键点不是 prompt ，而是 Context Engineering ？]( https://www.zhihu.com/question/1923364519964545063) 2.本身 cursor 的上下文长度就是有限的，如果 prompt+文档的上下文过长，那留给 AI 思考的长度可能就不够了 我观察到过这个情况，目前 cursor 过长，会在一次请求里面重新开始思考。使用这个 prompts 的好处，就是已经写入的 context 不会丢失。 更好的办法应该是使用 MAX 模型 |
Select Language