零幻觉编码器

解决什么问题

大模型写代码最常见的失败不是语法错误，而是自信地编造：调用了不存在的方法、引入了项目里根本没装的包、跳过部署前置条件直接写最终集成，或者在缺少上下文时补一段看似合理但无法运行的逻辑。

这类问题在改一行 typo、写个临时脚本时代价不高；但一旦涉及数据库迁移、鉴权调整、跨文件重构或外部 API 接入，一次幻觉可能直接进入生产。zero-hallucination-coder 针对的正是这个场景：它不承诺“更快出代码”，而是把高风险修改约束成可审查、可回退、可验证的流程。

它如何工作

这个技能采用显式 opt-in 的五阶段循环，核心目标是：代码必须正确、有依据、且完整。

• Phase 1: Discuss：先用一段话澄清终点状态、技术栈、受影响代码、硬约束和验收标准。问题没答清前不进入规划。
• Phase 2: Map：写代码前先建立代码库地图，对现有逻辑或新架构中的依赖做标记，例如 [KNOWN]、[ASSUMED]、[UNKNOWN]。
• Phase 3: Decompose：把任务拆成原子故事。规则很具体：单个故事超过约 300 行、触及超过 3 个文件，或验收标准超过 2 条，就继续拆。
• Phase 3.5: Ponytail Check：每个故事动手前先问“这段代码是否真的需要存在”，优先用标准库、原生能力或已安装依赖消除整段实现。
• Phase 4: Execute：一次只实现一个故事，不允许占位实现、// TODO 或凭空 import。不确定的 API 必须标注 // ⚠ ASSUMED: ...，并在进入下一步前解决。
• Phase 5: Verify：把实际产出对照计划逐项验收；发现缺口就补一个 micro-story，再单独走实现与验证。

贯穿全程的还有 7 条 anti-hallucination 规则：不发明 API、不默认 import、不静默假设、不跳过单测级验证、不把多个故事塞进同一次回复。它融合了 Ralph 的原子提交式循环、GSD Core 的上下文纪律、Graphify 的 KNOWN/INFERRED/UNKNOWN 标注，以及 Ponytail 的“少写代码”审查。

适用边界

这套流程不适用于所有编辑。格式调整、文档字符串补全、一次性脚本或单行修复，直接进入五阶段循环通常得不偿失。

它更适合：难以撤销的迁移或部署变更、跨多文件的现有系统扩展、涉及外部 API/数据库/鉴权的改动，或者用户明确要求“先规划、别臆造”的任务。使用时需要你提供关键上下文，尤其是受影响文件、真实依赖版本和硬约束；上下文越少，技能越依赖 [UNKNOWN] 标注，流程也会更重。