该方法论提供了一种结构化的方法，用于在软件开发项目中与人工智能系统协作。它通过系统约束和验证检查点解决了诸如代码膨胀、架构漂移和上下文稀释等常见问题。
人工智能系统以“问题→答案”的模式运作，当你寻求广泛、多方面的实现时，你通常会得到：
- 功能有效但缺乏结构
- 跨组件重复代码
- 会话中的架构不一致
- 上下文稀释导致输出漂移
- 调试时间比规划时间更多
工作原理
该方法分为四个阶段，并设置了系统约束和验证检查点。每个阶段都基于经验数据而非假设。
规划可以节省调试时间。提前周密的规划通常可以避免日后花费数天时间修复架构问题。
四个阶段
第一阶段：AI配置
使用AI-PREFERENCES.md设置 AI 模型的自定义指令。这将建立行为约束和不确定性标记，⚠️当人工智能缺乏确定性时的指标。
第二阶段：协作规划
与 AI分享METHODOLOGY.md文件，构建你的项目计划。携手合作，实现以下目标：
- 定义范围和完成标准
- 识别组件和依赖关系
- 根据逻辑进展构建阶段
- 生成具有可衡量检查点的系统任务
第三阶段：系统实施
分阶段、分部分地开展工作。每个请求都应遵循以下要求：“您能实现[特定组件]吗？”并明确目标。
文件大小保持在 150 行以内。此限制规定：
- 用于处理的上下文窗口较小
- 专注于多功能尝试的实施
- 更轻松的共享和调试
Request specific component → AI processes → Validate → Benchmark → Continue
第四阶段：数据驱动迭代
基准测试套件（首先构建）在整个开发过程中提供性能数据。将这些数据反馈给人工智能，以便基于测量结果而非猜测做出优化决策。
为什么这种方法有效
好的，直接大白话翻译：
为啥这个方法好使？
1. 下指令要一个一个来： 你问它“你能干A吗？”，它很清楚；但是你咣咣咣甩过去一长串“能干A、B、C、D、E、F、G、H吗？”，它就容易懵圈、漏活儿。
2. 别让它想太多事儿： 把大问题拆成一个个小问题，一个文件只解决一件事；别让它同时琢磨好几件不相关的活儿，它脑子会乱。
3. 不看广告看疗效： 别管它自己觉得行不行，直接拉出来遛遛，跑个分、测一下性能。行就是行，不行就是不行，用结果说话。
4. 立好规矩，别让它瞎搞： 用硬性规定卡死，比如：文件不能太大、必须通过某些检查、不能随便调用其他东西。这样它就没办法偷懒或者跑偏，只能按规矩办事。
示例项目
- Discord Bot 模板- 可立即投入生产的机器人基础，具有插件架构、安全性、API 管理和全面测试。46 个文件，均少于 150 行，并带有基准测试套件和自动合规性检查。（查看项目结构）
- PhiCode Runtime - 具有转译、缓存、安全验证和 Rust 加速功能的编程语言运行时引擎。复杂的系统在 70 多个模块中保持架构规范。(查看项目结构)
- PhiPipe - 具有统计分析、GitHub 集成和并发处理的 CI/CD 回归检测系统。基于 Go 的服务处理性能基准和自动回归警报。(查看项目结构)
什么问题促使您创建这个方法论？
我真是受够了！不管我用什么语言、做什么项目，这AI总是一个德行：我得跟个复读机似的，一遍遍跟它重复我的喜好和架构要求。结果它还是老给我生成那种又胖又乱、全塞在一起的“屎山代码”，或者搞些半吊子功能， bug 还贼多。
这事儿逼得我去琢磨，到底什么最根本的原则在驱动代码质量和软件架构。我开始想，AI这“模式匹配”的脑子，是不是更适合去学那些底层的软件设计原则，而不是死记表面上的语法糖？
因为它的运作逻辑说到底是“逻辑”，是靠简单的“一问一答”来驱动的。
我算明白了，你让它一个函数干八件事，它CPU都得干烧了，压力太大了。
我最大的突破是想通了一点：甭管多花里胡哨，最后一切都会落回到最底层的二进制——说白了就是一连串的 “这事你能办不？” → “能/不能” 的简单问答。
这下我彻底开窍了，方法全变了：
- 别下命令了，得在合适的时机，问它一个精准的问题。
- 别自己一个人在心里盘算超级复杂的架构，然后让它猜，得跟它一起，一步一步地、有章法地把计划制定出来。
您是如何发现这些特定的限制有效的？
（经过）海量的、不停的试错（得出的结论）。
就算你给它立好了规矩，AI 也总是会跑偏。但是，有规矩管着的AI，比那没规矩的，准得多得多！
有时候你得提醒它一下“记住你的身份”，防止它跑偏——这就好比管一个特别想讨好你、心眼不坏的小孩子。他知道规则，但有时候为了让你高兴，他会忍不住试探着越界。
这些工具远非完美，但只要用合适的条条框框约束好，它们就是软件开发中非常得力的帮手。
为什么是150行呢？
多重好处：易于阅读、清晰理解、模块化执行、架构清晰、维护简单、组件测试、最佳 AI 上下文保留、可重用性和遵守 KISS 原则。