- 禁止为纯理论、低概率的边界情况增加兜底逻辑。例外：用户明确要求，或涉及数据损坏、资源泄漏、安全问题。
假如不加这一条，AI 会习惯把各种极端假设情况都考虑到，写长长的防御性代码占满你的屏幕
这种代码撸棒性拉满，但是对人类来说阅读维护成本更高，不符合开发效率优先的现状
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
 |
1
QAO 5h 58m ago
但是万一某些场景真的是你此时此刻没想到的呢？古法编程时期，因为没考虑到各种 edge case 引发的线上故障又回来返工的例子不要太多，屎山很多就是修修补补这么来的，倒不如想清楚一次性做好设计，写好代码
|
 |
2
loading 5h 43m ago via Android  1
op 实属搞笑。
|
 |
3
pakro888 5h 9m ago
ponytail
|
 |
4
lscho 5h 7m ago via Android
|
 |
5
dreamkuo 4h 52m ago
我赞成这个观点, 我觉得非常有意义, 因为安全性存在边际递减效应. 百分之九十的代码 解决不到百分之 0.1 的安全性, 这简直就是浪费生命. 消耗的上下文能力,和人工审查 反而遗漏了严重的漏洞.
|
 |
6
alexluo1 PRO 这个我早加上了，我写的是：不得用假数据、固定成功或空集合掩盖未实现逻辑。未实现能力应显式返回可识别的业务错误，或保持在路线图中而不暴露虚假接口
|
 |
7
little_cup 3h 52m ago
差不多，我写的是：
``` 禁止防御式编程，禁止嵌套守护式代码，凡是能事件驱动的禁止轮询，禁止内文注释超过 5 行，禁止任何针对接口形状的测试。 核心原则：删代码 > 加代码。 ``` AI 写得是快，但是如果放任代码套娃叠套娃要不了多久，维护难如登天。每一层新的状态机都靠上层状态机的巧合和 bug 运行下去。 我每周会拿一晚给 Fable 和 5.6 sol 做互相对抗审查，比谁删代码删得多。 |
Select Language