引言
Disciplined AI Software Development 项目是由 Varietyz 在 GitHub 上开源的一个方法论框架，旨在为开发者与人工智能（AI）系统协作进行软件开发提供一种结构化的方法。该项目地址为 https://github.com/Varietyz/Disciplined‑AI‑Software‑Development，仓库中包含核心文档如 METHODOLOGY.md、AI‑PREFERENCES.md，以及配套脚本如 project_extract.py。该方法论针对 AI 协作开发中常见的痛点，如代码膨胀（code bloat）、架构漂移（architectural drift）和上下文稀释（context dilution），通过系统性的约束和验证检查点来提升开发效率和代码质量。项目强调从规划到迭代的全流程控制，适用于从简单脚本到复杂系统的各种软件项目。截至 2025 年，该仓库尚未发布正式版本，但提供了详细的 README 和流程图，便于开发者快速上手。整个方法论的核心在于将 AI 的“问题‑答案”模式转化为可控的、数据驱动的开发过程，避免无序交互导致的低效。
该方法论的灵感来源于作者在实际开发中的挫折，例如 AI 生成的代码往往缺乏结构、重复冗余，或在多会话中失去一致性。通过试验，作者发现施加文件大小限制（≤150 行）和分阶段实施能显著改善输出质量。项目适用于有编程基础的开发者，特别是那些厌倦了 AI 生成的“维护地狱”（maintenance hell）的用户。接下来，我们将详细概述其核心内容，并提供操作细节，帮助读者实际应用。
问题描述与方法论基础
传统 AI 协作开发往往采用“一次性大请求”模式，例如直接要求 AI 实现多个功能，这会导致输出漂移：函数虽能运行但架构不一致，代码重复，调试时间远超规划。作者指出，AI 本质上是基于模式匹配的“问题‑答案”系统，处理复杂多面任务时容易出错。该方法论通过四个阶段解决这些问题：AI 配置、协作规划、系统实施和数据驱动迭代。每个阶段强调经验数据而非假设，规划先行以节省后期调试。
为什么有效？因为它将决策分解为小块：AI 更擅长处理单一“能做 A 吗？”而非“A 到 H”的多任务。同时，小文件和边界约束减少上下文负载，经验验证（如基准测试）取代主观判断。操作上，该方法要求开发者严格遵守约束，例如文件行数上限，以强制一致性。
四个阶段的详细操作
阶段 1: AI 配置
这一阶段设置 AI 的行为规范，使用仓库中的 AI‑PREFERENCES.md 作为自定义指令。操作细节：首先，复制 AI‑PREFERENCES.md 的内容到 AI 模型的自定义指令区（如 ChatGPT 或 Grok 的设置界面）。该文件定义了 AI 的行为约束，例如要求输出时标记不确定性（用 ⚠️ 符号），并强调遵守 KISS（Keep It Simple, Stupid）原则和 SoC（Separation of Concerns）架构。
实际操作：登录 AI 平台，进入设置，粘贴 AI‑PREFERENCES.md 全文。测试配置有效性：输入一个简单查询，如“描述一个函数”，检查输出是否包含不确定性标记。如果 AI 忽略，立即提醒“遵守 AI‑PREFERENCES.md”。这一步确保 AI 从一开始就遵循方法论，减少后期偏差。
阶段 2: 协作规划
与 AI 共同制定项目计划，分享 METHODOLOGY.md。操作细节：将 METHODOLOGY.md 的内容复制到 AI 对话中，作为上下文。然后，引导 AI 定义项目范围、完成标准、组件和依赖。例如，输入：“基于 METHODOLOGY.md，帮我规划一个 Discord Bot 项目，包括范围、组件和阶段。” AI 会输出一个依赖链式的开发计划，分阶段（如 Phase 0 为基础设施）。
关键操作：识别组件依赖，使用逻辑顺序结构化阶段；文档边缘案例但不实施代码。输出应是带检查点的计划文档。开发者需迭代：如果计划模糊，请求澄清（如“添加可衡量的检查点”）。这一阶段通常需 1‑2 小时，确保后续实施有序。
阶段 3: 系统实施
分阶段、分组件实施，每个请求聚焦单一组件。核心约束：文件 ≤150 行。操作细节：从 Phase 0 开始，必建基准测试套件（benchmarking suite）。例如，请求 AI：“实现基准测试基础设施，用于测量运行时间和资源使用。” AI 生成代码后，开发者验证：运行代码，检查行数（用脚本或手动计数）。如果超限，立即反馈：“‼️ 架构违规，拆分成多个文件，遵守 SoC。”
流程循环：请求组件 → AI 生成 → 验证 → 基准测试 → 继续。使用仓库脚本 validate‑phase.py（假设仓库有此脚本，根据描述推断）自动化检查文件大小和结构。针对多语言项目，需文档性能理由（如 Rust 加速），并测量益处。多组件时，按依赖顺序实施，每次交互限一组件。实际中，开发者应在本地 IDE（如 VS Code）中测试生成代码，运行基准（如时间测量脚本），并分享结果给 AI 以优化。
阶段 4: 数据驱动迭代
基于基准数据优化。操作细节：Phase 0 后，每组件实施后运行基准套件，保存基线（如使用 GitHub Workflows 自动化）。例如，运行“benchmark.py”生成报告，输入 AI：“基于此基准数据（粘贴报告），优化组件 X 以减少 20% 运行时间。” 如果回归（regression）检测到性能下降，阻塞进度，请求 AI 修复。
工具支持：使用 project_extract.py 提取项目状态。操作：配置 scripts/project_extract.py 中的 SEPARATE_FILES=False（小项目单文件输出），INCLUDE_PATHS 为项目目录，运行“python scripts/project_extract.py”。输出包括语法高亮代码、行数警告（⚠️ 为 140‑150 行，‼️ 为 >150 行）和树状结构。将输出分享给 AI 以维持上下文。质量保障包括 DRY（Don't Repeat Yourself）审计和依赖验证，使用自动化脚本如 dry‑audit.py。
示例项目与实施步骤
仓库列举了三个示例：Discord Bot Template（46 个文件，插件架构）、PhiCode Runtime（70+ 模块，Rust 加速）和 PhiPipe（CI/CD 系统，Go 代码）。这些项目展示方法论的应用：所有文件 <150 行，带基准和自动化检查。查看项目结构链接可看到实际代码组织。
整体实施步骤：
- 设置 AI 配置（5‑10 分钟）。
- 分享 METHODOLOGY.md 并协作规划（30‑60 分钟）。
- 构建 Phase 0 基础设施（1‑2 小时）。
- 顺序实施阶段，每次运行一组件，运行基准和提取状态（迭代循环）。
- 质量门控：使用 CI/CD 工作流如果审计失败（如 GitHub Actions）阻塞合并。 对于大型项目，设置 SEPARATE_FILES=True 以分目录输出状态。开发者需定期审计：运行 architecture‑auditor.py 检查 SoC 合规。
为什么有效及 FAQ 洞见
该方法减少调试周期，提升代码可维护性。通过约束，AI 输出更可靠；数据迭代确保优化基于测量而非猜测。FAQ 揭示作者背景：从 2024 年 8 月开始 AI 编程，累计 6700+ 小时经验。常见错误如期望 AI 完美，被方法论避免。学习曲线因人而异，但对有基础者友好。不适合简单脚本或无规划偏好者。
作者强调适应性：如果项目不符，可调整方法。个人实践：严格遵守，偏差时立即旗标纠正。整体，方法论像“驯服 AI 的 toddler”，通过边界和提醒维持纪律。
结论
Disciplined AI Software Development 提供了一个实用框架，将 AI 从“哑工具”转化为可靠伙伴。通过详细的操作细节，如配置指令、组件请求循环和自动化提取，用户可高效构建高质量软件。仓库的流程图可视化了整个工作流，便于跟踪。该方法不仅解决当前痛点，还为未来 AI 协作铺路。建议开发者克隆仓库，立即尝试一个小项目，以体验其效益。