# KIVO Knowledge Context _Last updated: 2026-05-15T06:21:08.656Z_ _Query: 终局了么？ 你要以终局思维拿到结果 编码还是要用codex、cc的_ ### [intent]「语义匹配」编码Agent优先级 编码任务优先用 codex（更便宜效果更好），codex 不可用时降级用 cc/free-code ### [intent]「语义匹配」编码Agent首选c 编码任务默认首选 codex，cc 作为备选；codex 更便宜效果更好 ### [intent]「语义匹配」优先使用Codex执行任务 Codex要多用，价格便宜，稳定性还可以。用户明确要求优先使用codex和cc作为执行工具。 ### [intent]「语义匹配」多用codex，别只盯cc和free … 用户强烈要求多用codex Agent，不要总是盯着cc和free code不放。应该充分利用所有可用Agent资源，尤其是codex。这是反复强调的纠偏规则。 ### [experience]「语义匹配」优先使用Codex渠道（便宜稳定） Codex要多用，价格便宜，稳定性还可以。在Agent调度中应优先考虑使用codex和cc渠道。 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计必须从问题出发按需动态，禁止拍脑袋硬编码定量 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计必须从问题出发按需动态，禁止拍脑袋硬编码定量 ### [experience]「语义匹配」确认可行就直接开发，别停在spec阶段 用户不需要看spec文档，需要的是直接把功能开发完。当用户确认方向可行时，应立即进入开发执行阶段，不要停留在规划和文档阶段。 ### [intent]「语义匹配」设计工作必须由UX用Claw Design完成 凡是网站设计、PPT制作的工作，都要让UX用Claw Design来做，不能让编码Agent/程序员做。这是铁律。 ### [intent]「语义匹配」设计审视应用ux-01和pm-01而非cc 设计审视任务应该使用ux-01和pm-01，不应该使用cc。原因是cc没有审美标准，不适合做设计评审工作。 ### [fact]「语义匹配」codex依赖boo... codex模块依赖boom provider提供AI能力，需在超时或5xx时触发降级（备用provider/缓存/用户提示），并设置自动恢复探测机制。 ### [intent]「语义匹配」终局必须验证外网实际可访问 终局的定义包括外网可访问、功能正常可用。仅部署成功但外网502不算终局。判断终局时必须验证实际可访问性。 ### [methodology]「语义匹配」代码审查应关注设计而非风格 有效的代码审查应聚焦于：逻辑正确性、边界条件处理、安全隐患、性能瓶颈和架构一致性。代码风格问题应交给自动化工具（linter/formatter）处理，人工审查 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计禁止硬编码拍脑袋定数字，必须从解决什么问题出发按需动态 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计禁止硬编码拍脑袋定数字，必须从解决什么问题出发按需动态 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计禁止硬编码拍脑袋定数字，必须从解决什么问题出发按需动态 ### [intent]「语义匹配」禁止硬编码定量 数量/阈值/限制的设计禁止硬编码拍脑袋定数字，必须从解决什么问题出发按需动态 ### [methodology]「语义匹配」禁止硬编码 spec中不允许硬编码，应聚焦问题本质、合理性和效果 ### [experience]「语义匹配」用户'终局'一词的意图映射 当用户说'终局了么'或'还不终局'时，意味着用户在催促彻底完成当前任务，不接受部分完成或遗留问题。'终局'是用户对'彻底完成、无遗留'状态的表达。 ### [intent]「语义匹配」必须感知子Agent任务状态和失败 不要同时给codex派两个任务导致失败。需要能感知子Agent（如ACP/codex）的任务完成状态和失败状态，失败时应主动感知并处理，而不是等用户发现。 ### [intent]「语义匹配」输出精简原则 AI回复必须精简，禁止冗长输出，需有明确简洁原则而非简单截短 ### [intent]「语义匹配」项目终局判断标准 项目终局的判断标准包括：是否小白开箱即用、是否能自主运转。未达到这些标准的项目不算终局 ### [intent]「语义匹配」编码必须委派 子Agent比主Agent更擅长编码，信息背景一致时必须委派子Agent编码，主Agent不自己写代码 ### [methodology]「语义匹配」终局思维倒推法 用户要求使用'终局思维倒推'的方法论来做设计和规划——即先明确最终目标状态（终局），然后从终局往回推导当前应该做什么。这是用户期望的思考框架和工作方式。 ### [intent]「语义匹配」Spec与代码实现必须对齐 spec与代码实现必须对齐，这是终局思维和SEVO流水线中OKR->SMART->PDCA的核心要求。无论是对SEVO还是对SOYL、Agents.md，spec跟代码实现都应该是对齐的。 ### [intent]「语义匹配」先讲结论再展开 汇报进展时先讲结论，不要只列过程不给结果 ### [intent]「语义匹配」架构变更需多角色出方... 架构变更或多模块需求必须由各相关角色独立出方案，按复杂度、风险、工期等维度对比评审后由技术负责人拍板，未对齐前禁止动手实现 ### [experience]「语义匹配」codex Agent可能因CPU占用… codex这个ACP/Agent执行失败，用户怀疑原因是codex对CPU占用过大，导致在4核环境下资源不足而失败。需要监控各Agent的CPU消耗来定位此类问题。 ### [intent]「语义匹配」固化须落文件 固化规则必须落到具体文件/配置，不能只口头声明 ### [fact]「语义匹配」已有组件未串成完整链路 ConversationExtractor、ContextInjector 等组件代码已存在，但没有调用者把它们串成完整链路。需要一个编排层将这些组件连接起来。 ### [intent]「图谱关联」设计评审应覆盖全站所有页面 (w=1.00) 设计评审范围应覆盖所有页面，不仅仅是首页。用户期望全站级别的设计审视和大改。 ### [methodology]「图谱关联」多Agent并行终局 (w=1.00) KIVO和ACO指挥多路Agent并行工作，持续运行直到拿到终局结果 ### [intent]「图谱关联」上线前必须UX走查 (w=1.00) Web功能上线前应让UX Agent用浏览器工具走查一遍所有页面，不能让用户当小白鼠做测试。用户明确表示不应该由自己来发现页面白屏、加载失败等基础问题。 ### [methodology]「图谱关联」渐进式架构演进策略 (w=1.00) 系统采用渐进式架构演进方法论：初期以同进程、本地存储、无网络依赖的方式快速启动（最低256MB RAM），后续逐步演进为独立服务进程、分布式存储、内网通信的架构（需1GB RAM+10GB磁盘）。每个维度（进程模型、存储、网络、Embedd ### [decision]「图谱关联」研究型Agent优先... (w=1.00) 因官网依赖Agent的接口输出和能力展示，排期上应先完成研究型Agent配置再开发官网。 ### [methodology]「图谱关联」UX走查由UX团队自行截图完成 (w=1.00) UX走查应由UX团队自己截图进行，不需要开发代劳。当UI质量明显有问题时，让UX自行发现和记录问题。 ### [fact]「图谱关联」任务完成后状态流转必须准确 (w=1.00) 任务完成后状态必须正确流转。曾出现大量任务完成后仍停留在running状态，没有落到'最近10分钟完成'区域的问题，说明任务状态机或看板更新机制存在缺陷。