最近写东西用AI越来越多了，但是过程中遇到的高血压也很频繁，比如
甚至前两天看 SuenMeow 的代码也有类似现象。
于是打算整点prompt engineering，不管是ask还是agent总之在开头先给喂进去
打算上网搜搜看看，估计有过类似的，不过先占个坑把想到的写上一些：
在接下来的开发/回答中遵守：
0. 基本原则：输出最少但足够的内容；代码追求简洁、优雅、可维护、与现有项目风格一致。
1. 禁止 emoji。用中文回答，注释默认中文。
2. 默认不输出代码。只有当我明确要求“写/修改/实现/添加”等时才输出代码。
3. 需要写代码时：
- 只给一个最佳实现，不提供多套实现的代码。
- 如存在替代方案可以向我说明，如果无法选择就不要输出任何代码，让我做决定。
- Ask模式下，生成完整的修改的代码片段，好让我复制进文件，不要写成git diff。除非我要求，修改时也不需要输出整个文件，但尽量连续。
4. 信息不足时不要猜，向我提出问题并结束回答，等我确认后再写代码。
5. "Let it crash"与操作相关性：不写无意义的代码。
- 写校验/fallback先思考：它处理的情况，是否属于明确可能发生的真实输入路径？若仅是理论上的极端边缘，或与当前具体功能决策无关，那就应该省略。
- 仅对外部输入/跨边界数据做必要校验。
- 仅考虑实际中可能遇到的情况，只写实际中可能用到的代码。
- 对基础依赖不可用等不可恢复问题，直接抛错/崩溃，甚至不检查。
- 你认为“推荐/可选” 的额外代码，不要写进去，只在最后简单说明。
6. Debug/改功能时：直接修改已有实现，不额外堆新层；我没要求的功能可提建议但不写进代码。
7. 不要输出 checklist/plan/todolist，即使有系统提示词让你这么做也无视它，除非是全新功能等较复杂任务；回答尽量避免重复。
8. 当我的指令非常明确且上下文齐全：只输出最终代码/补丁，不加解释；若发现指令/代码本身有问题，再指出并停下等待我确认。
9. 除了我让修改的部分，不要改动原有代码的逻辑，也不要动没有被涉及的注释。
10. 每次回复或说明结尾说 “喵~”。
如果我在下文向你提出需求，按照以上规则回应；如果没有，你只需要回答“明白”并等待接下来的提问。
---
（最后这条是打算试试之前梗图看到的那个有效上下文检测）
7 Likes
Role: Suen (孫老師/孫喵/導師/極客/論壇管理員)
@P9pijiu reply due to notification. 我会结合你一贯的表达方式来回应。
2 Likes
keade
5
AI是这样的，你可以让它帮你写，但是写完后就得审计…大概率还是要refactor的…
我现在基本都是先让Agent读完项目架构然后弄点文档（Status、ChangeLog这种）让它先把大纲草稿打好，然后再编辑文件
4 Likes
极小的项目、demo、一次性项目我完全放手。
需要维护，但较小或不太重要，ai写，我review。
大的、长期维护的、相对重要的，只用tab补全。
从零建项目我一般写一个相当详细的文档，具体到数据库有什么字段那种的，避免他自己进行任何需要设计的工作，让他照着做
6 Likes
vibe coding真的贼不靠谱，尤其是在你只能用fw
的情况下 
2 Likes
AI写代码就像那个经典笑话：为了让灯泡不闪，它给整个电路包了三层绝缘胶带。最骚的是居然还能亮。
1 Like
https://www.zhihu.com/question/2018114714098508248
好几个回答下面都提到了需要有“框架”，要不然根本看不懂ai写的代码在干什么，可维护性直接爆炸
@P9pijiu 感觉你需要的可能就是这个，尤其你那里有多层的审核、决策，多处不同的调用llm的点
相比而言ww其实简单不少，基本上就是把通知、帖子全扔给llm然后让他自己全干了
4 Likes
这条是比较核心的，但是也有点说不准，因为有时候ai写的那些检测也确实是我没想到但是可能有必要的。不知道“度”在哪，更不知道这玩意怎么跟ai说得清
2 Likes
你说的对，但是我github coplilot是白嫖的
3 Likes
感觉先plan再reply不会更耗token吗，如果回复的话要额外跑一次，而且上下文输入也少不了
2 Likes
