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