他们不让 agent 写 useEffect，linter 直接拦住

在 AI Engineer Code Summit 的 Day 1 workshop 上，@factory 的 @ross_cefalu 讲了一个很具体的做法：在 @factory，agents 不能加 useEffect。linter 会拒绝。

useEffect 是 React 里处理副作用的钩子，容易引入隐式行为。@factory 把这条规则交给 linter，不靠 agent 自觉。这个细节很小，但有用。agent 生成代码时，口头规范经常被忽略；linter 把规则变成硬失败，agent 才会改。让 agent 写代码，最后还得靠 linter 当门卫。

视频来自 @aiDotEngineer 的推文，Ross Cefalu 讲的是如何用 agents 更容易执行有主见的代码标准。这里的关键词是有主见。标准要具体到能检查，能拒绝，能重复。

但 linter 也有覆盖不到的地方。回复里，IronRed 提到自己在做 How-Could-I-Be-Hacked，目标是让 agents 检测绕过 linter 的 sneaky useEffect。这个方向补上了 linter 的盲区。规则能拦住正常路径，绕过规则的行为需要另一层检查。

外链里的说明写得很清楚：这个库给 coding agent 提供真实安全调查上下文，用在代码审查里。它包含 37 个匿名案例、113 个调查与审查步骤、475 条搜索条目。工具本地跑，用 Python 和 SQLite，不需要 API key。

用法不复杂。安装 Skill 可以用：

npx skills add sandhiveio/How-Could-I-Be-Hacked --skill how-could-i-be-hacked

然后在有权限审查的仓库里让 agent 用 $how-could-i-be-hacked 审查代码，匹配案例，解释哪些检查适用，把本地确认的问题变成回归测试。也可以直接跑 corpus.py search 按关键词查案例，比如查 credential masking formatter。

案例目录里既有 SQL 注入、HTTP 请求走私、JWT 算法混淆，也有支付、旅行、日历、消息工作流里的 prompt injection。防御审查示例包括 OIDC client-secret 脱敏、上传目录 containment、归档解压 containment。每条带调查步骤和证据上下文，能直接读。

回到 @factory 的做法。给 agent 立规矩有两层。第一层是让错误写不进来，linter 直接拒绝。第二层是让绕过规则的行为有案例可查，有测试可回归。第一层靠工程约束，第二层靠安全上下文和回归测试。两层都做，agent 写代码的速度才有工程意义。

来源：
@aiDotEngineer 的推文
How-Could-I-Be-Hacked
Skills CLI