codex的代码写的太复杂了，怎么写全局提示词，让他输出简洁代码

我的建议是今天休息，然后期待一下明天新发布的5.6

还经常骗我，天天给我兜底，正常应该报错的，结果写个except给我造个数据输出来了

安装 skill, 写代码让它使用 ponytail skill, 日常交流使用 caveman skill，佬友可以研究一下

哈哈哈哈哈笑死我了，他最会的事情就是兜底了，兜的一手烂底

好的佬，我之前用superpowers感觉对代码没什么约束，我看看ponytail skill

同感，是真喜欢catch啊。。。。该报错的不报错，人麻了，各种||,??，就是说非得要有数据吗^-^

安装 skills，这个你在论坛找找，应该有推荐的，

当然是请ponytail 出马啊

我还以为是我技术太菜，能不兜就不兜，没想到是ai在瞎兜

今天用grok4.5寫了一整天 感覺很舒服

寫的代碼比5.5寫的代碼好看多了 像自己手寫

但問題是5.5一review 發現bug一大堆

還是得被5.5穩穩的接住

今天又是打比赛，又是准备发布新模型，算力早不够了 ^-^

ponytail和caveman，这两个skill适合看不懂代码的人使用吗？我看用了，会让对话变得非常简洁，而且很省token

caveman skill

两个都安装了话，手动切换吗？正确姿势是怎样？

我都是连环使用的，先多花点精力用 gpt 5.5 对齐设计，最后一股脑用 gpt 5.4 模型实现，佬友可以参考一下下里边的几个 skills 自己整合一套适合自己的方式。

使用 planning-with-files skill，并严格按其流程执行：开始复杂任务前先按该 skill 的约定初始化规划材料，不要只创建不更新；执行过程中持续维护，在每个阶段完成后、每次关键发现后、出现错误时及时更新，重要决策前先回读相关内容，避免上下文丢失。相关规划材料的创建与更新不受任何写入限制。

使用 grill-me skill，对当前方案/设计进行高强度评审与追问。交互方式：一次只提一个问题，等待我回答后再继续下一问；若同时存在多个关键分歧，按风险和前置依赖从高到低依次追问。补充约束：重点覆盖并不限于目标与成功标准、范围边界与非目标、前置假设与约束、接口与数据流、依赖关系、失败场景与降级策略、风险、安全/性能/兼容性/可观测性影响、迁移与回滚方式，以及测试验证与验收标准；关键分歧或前置决策未澄清前不要编码；若发现问题过大或边界混杂，先协助拆分；达成共识后简要整理已确认决策、待确认事项、主要风险和建议下一步。

有任何不清楚、存在歧义、信息不足或需求边界不明确的地方，先向我询问并确认后再继续。不要自行猜测或替我补全未明确的信息。提问时给出带字母编号的清晰选项（如 A/B/C，必要时继续 D/E），让我可以直接回复字母；并标注你的推荐方案及简要理由。

使用 caveman skill，强度 full：后续回复在保持技术准确性的前提下尽量短；去掉客套、铺垫和重复说明；保持我使用的语言；不要解释已开启该模式。涉及安全警告、不可逆操作确认或容易误解的多步骤流程时，先用正常清晰表达，之后恢复简短模式。

在与技术实现直接相关的阶段参考 ponytail skill，包括实现方案细化、局部代码结构设计与具体编码；优先复用现有能力，避免多余抽象，在保证正确性和安全性的前提下采用最短可行实现。不要将该 skill 用于需求澄清、业务或产品方案设计、整体架构方向评审、流程讨论或其他非实现导向的决策简化。

前阵子流行过的“我是一个智力低下的大学生/不懂科技的老奶奶，请用我能看得懂的方式写代码”

出来的东西不一定好用，但起码能看懂

这是我写的提示词，佬友可以试试，或者试试ponytail和trellis，都挺好使的

这些是 AI 写代码时的常见问题，主动避免：



- **过度注释**：不要给每一行都加注释，注释应该解释意图而非复述代码

- **无意义重构**：不要把能跑的代码改成"更优雅"但行为发生变化的版本

- **功能蔓延**：只做需求里要求的事，不要自作主张加"顺手实现的功能"

- **忽略边界情况**：不要省略错误提示和边界处理，假设用户一定会按预期使用

- **大段替换**：不要动不动就重写整个文件，优先在原有基础上做最小改动