- 禁止为纯理论、低概率的边界情况增加兜底逻辑。例外：用户明确要求，或涉及数据损坏、资源泄漏、安全问题。
假如不加这一条，AI 会习惯把各种极端假设情况都考虑到，写长长的防御性代码占满你的屏幕
这种代码撸棒性拉满，但是对人类来说阅读维护成本更高，不符合开发效率优先的现状
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
 |
1
QAO 21h 40m ago
但是万一某些场景真的是你此时此刻没想到的呢？古法编程时期，因为没考虑到各种 edge case 引发的线上故障又回来返工的例子不要太多，屎山很多就是修修补补这么来的，倒不如想清楚一次性做好设计，写好代码
|
 |
2
loading 21h 25m ago via Android  1
op 实属搞笑。
|
 |
3
pakro888 20h 50m ago
ponytail
|
 |
4
lscho 20h 48m ago via Android
|
 |
5
dreamkuo 20h 34m ago
我赞成这个观点, 我觉得非常有意义, 因为安全性存在边际递减效应. 百分之九十的代码 解决不到百分之 0.1 的安全性, 这简直就是浪费生命. 消耗的上下文能力,和人工审查 反而遗漏了严重的漏洞.
|
 |
6
alexluo1 PRO 这个我早加上了，我写的是：不得用假数据、固定成功或空集合掩盖未实现逻辑。未实现能力应显式返回可识别的业务错误，或保持在路线图中而不暴露虚假接口
|
 |
7
little_cup 19h 34m ago
差不多，我写的是：
``` 禁止防御式编程，禁止嵌套守护式代码，凡是能事件驱动的禁止轮询，禁止内文注释超过 5 行，禁止任何针对接口形状的测试。 核心原则：删代码 > 加代码。 ``` AI 写得是快，但是如果放任代码套娃叠套娃要不了多久，维护难如登天。每一层新的状态机都靠上层状态机的巧合和 bug 运行下去。 我每周会拿一晚给 Fable 和 5.6 sol 做互相对抗审查，比谁删代码删得多。 |
 |
8
skuuhui 9h 45m ago
如果你用顶尖模型。不建议加任何提示词，指导，指导，skills （私有技能除外，例如如何在你们的审批系统提交 pr ）。
全部去掉之后，你会发现他有些事情本来就是会的，而且你永远是水桶那一款短板。 |
 |
9
fuchen1024 9h 34m ago
还是得看具体场景，大型商业化系统还是万事考虑周全更稳妥。你说的其实就是“过渡设计”这个话题
|
 |
10
coder979 8h 26m ago
非常赞同 他能给我写好多 ||
|
 |
11
383394544 PRO 我喜欢这段
**KISS — Keep It Simple, Stupid.** 崇尚简洁与可维护性，避免过度工程化与不必要的防御性设计。能用 3 行代码说清楚的不写 30 行；能用直接调用解决的不抽象出 trait/Plugin/Strategy ；不为还没出现的需求预留扩展点；不为内部信任的代码补充防御性校验。三处类似代码胜过一个早产的抽象。 |
Select Language