最新我们CSDN一篇刷屏热搜把矛头指向了 Proton：员工建议"新代码上线前多花几天做安全测试"，CEO 直接回怼"That's bullshit and loser thinking"（这是失败者思维）。

随后剧情反转——CEO 取消全员 AI 复试，CTO 却发布工程宣言："编程已死，但工程没有死。"

这场风波里，最值得程序员深挖的不是八卦，而是一个被情绪掩盖的工程命题：当 AI 让写代码变快，安全、架构、验收该放在哪里？ 建议大家收藏。

---

一、先把热搜里最关键的两句话挑出来

1.1 CEO 的话："快速和安全当然可以同时做到"

热搜原文：

Andy Yen 在 Slack 上回应："这简直是胡说八道，是失败者的思维。快速和安全当然可以同时做到。" 还补充："不要总想着如何让事情变慢，应该多想想如何让事情变快。"

这句话对不对？ 作为工程师，我们必须冷静拆解：

• "快速和安全可以同时做到"——在架构合理、流程完备的前提下，是对的；
• 但热搜点破了前提："AI 可以快速生成代码，但生成得快，不代表代码就没有问题。"

问题不在"快"，而在"快之后有没有验证"。

1.2 CTO 的话："编程已死，但工程没有死"

CTO Bart Butler 的宣言核心是：

"未来工程师的职责将不再是亲自写出每一行代码，而是帮助 AI 更快、更好地完成开发任务。"
"编程已死，但工程没有死，专业能力也没有死。"

他还给出了一个极有启发的组织形态：

"每名工程师都应该成为一个小团队的负责人，只不过团队成员不再全是人类，而是由多个 AI 模型和智能体组成。"

这两个人说的话，其实指向同一件事的两面：CEO 讲"要用 AI"（效率），CTO 讲"工程不死"（质量）。真正的矛盾不是"用不用 AI"，而是"AI 变快之后，工程能力跟不跟得上"。

---

二、热搜里最扎心的细节：90% 代码由 AI 写，但安全谁负责

热搜给出的关键数据：

• 到今年 10 月，Proton 约 90% 的代码已由 AI 编写，大量借助 Claude；
• 公司还在员工电脑上安装软件，追踪 AI 生成代码的数量；
• CEO 曾称："2026 年将是公司最后一年招聘传统软件工程师；从明年开始，招聘更多产品经理，再借助 AI 构建产品。"

而那个被骂"失败者思维"的建议是什么？ ——"至少应该花几天时间对新编写的代码进行渗透测试（Pentest），确认没有安全问题后再部署上线。"

一句话点破：这不是"要不要用 AI"之争，而是"AI 生成的代码，到底谁来为安全背书" 之争。

作为一个写了多年程序的人，我必须说：员工的建议是对的。 因为——

"AI 可以帮工程师省下几天写代码的时间，却未必能替一家公司承担一次安全事故的代价。"（热搜原话）

2.1 这件事印证了一个趋势：瓶颈从"写"迁移到"验"

Proton 的 CTO 自己也承认了这一点：

"AI 已经能快速写代码，那么持续集成、设计审批、需求规格制定和代码审查，是否也需要重新设计？如果只让 AI 加快写代码，却不调整其他环节，效率提升最终还是会受到限制。"

这段话是全篇最有价值的——它说明连最激进的拥抱者，也承认了：光加快"写"，不加压"验"，等于把风险堆到了下游。

2.2 还有一个容易被忽略的点：CTO 承认"我们搞砸了"

"务实地使用 AI，并不代表公司要放弃安全、良好的架构设计和软件工程原则……我们搞砸了，我们知道自己搞砸了。"

这句话值得所有技术管理者抄下来：激进不等于正确，速度不能替代责任。

---

三、把"工程不死"变成可执行：一条代码验证生产线

光喊"工程不死"没用，得落到机制。下面我用 Python 实现一个"AI 生成代码的准入检查线"——把热搜里"渗透测试""代码审查""验收"这些概念变成可运行的多层门槛。可直接运行。

ai_code_gate.py

python

# -*- coding: utf-8 -*-
"""
AI 生成代码的准入检查线（AI Code Gate）
灵感来源：11.04 热搜——AI 生成 90% 代码，但"工程没死"，安全与验收必须留在系统里
设计理念：代码可以被 AI 快速生成，但"能不能上线"必须通过多层门槛
"""
from dataclasses import dataclass, field
from typing import Callable, List, Dict

@dataclass
class Gate:
    """一道准入关卡"""
    name: str                     # 关卡名：静态扫描/单测/安全/审查
    check: Callable[[str], bool]  # 返回 True = 通过
    blocking: bool = True         # 是否阻断上线
    risk: str = "mid"             # 该关卡拦截的风险等级

@dataclass
class GateResult:
    passed: List[str] = field(default_factory=list)
    blocked: List[str] = field(default_factory=list)
    warned: List[str] = field(default_factory=list)

# ---------- 四道关卡（示例规则，实际可替换为真实工具链）----------
def scan_lint(code: str) -> bool:
    """静态扫描：禁止调试残留"""
    return "print(" not in code

def run_unit_tests(code: str) -> bool:
    """单元测试：必须有测试"""
    return "def test_" in code

def security_pentest(code: str) -> bool:
    """安全渗透：禁止危险 API（对应热搜的 Pentest 诉求）"""
    dangerous = ["eval(", "exec(", "os.system(", "subprocess.call("]
    return not any(d in code for d in dangerous)

def human_review_signoff(code: str) -> bool:
    """人工审查签字：关键路径必须有人背书"""
    return "# REVIEWED_BY:" in code

GATES: List[Gate] = [
    Gate("静态扫描",   scan_lint,            blocking=True,  risk="low"),
    Gate("单元测试",   run_unit_tests,       blocking=True,  risk="mid"),
    Gate("安全渗透",   security_pentest,     blocking=True,  risk="high"),
    Gate("人工审查",   human_review_signoff, blocking=False, risk="high"),
]

def run_gate(code: str) -> GateResult:
    res = GateResult()
    for g in GATES:
        ok = False
        try:
            ok = g.check(code)
        except Exception:
            ok = False
        if ok:
            res.passed.append(f"{g.name}({g.risk})")
        else:
            (res.blocked if g.blocking else res.warned).append(f"{g.name}({g.risk})")
    return res

def can_release(res: GateResult) -> bool:
    """上线判定：只要有阻断关卡未通过，就不许上线"""
    return len(res.blocked) == 0

def report(code: str, label: str = ""):
    print("=" * 62)
    print(f"代码样本：{label}")
    print("=" * 62)
    res = run_gate(code)
    print(f"  通过: {res.passed or '无'}")
    print(f"  阻断: {res.blocked or '无'}")
    print(f"  警告: {res.warned or '无'}")
    print(f"  🚦 上线判定: {'✅ 允许' if can_release(res) else '❌ 拒绝'}")
    return res

if __name__ == "__main__":
    # 样本A：AI 快速生成的"裸代码"
    ai_raw = """
print('debug')
result = eval(user_input)
"""
    report(ai_raw, "AI 快速生成（未验证）")

    # 样本B：经过工程验证的代码
    ai_verified = """
# REVIEWED_BY: zhangsan
def calc(value):
    return int(value)

def test_calc():
    assert calc('42') == 42
"""
    report(ai_verified, "经工程验证的代码")

实测输出：

==============================================================
代码样本：AI 快速生成（未验证）
==============================================================
  通过: 无
  阻断: ['静态扫描(low)', '单元测试(mid)', '安全渗透(high)']
  警告: ['人工审查(high)']
  🚦 上线判定: ❌ 拒绝
==============================================================
代码样本：经工程验证的代码
==============================================================
  通过: ['静态扫描(low)', '单元测试(mid)', '安全渗透(high)', '人工审查(high)']
  阻断: 无
  警告: 无
  🚦 上线判定: ✅ 允许

这段代码对热搜的回应：

1. "快速"：AI 生成代码，速度不变；
2. "安全"：安全渗透作为阻断关卡，不通过就不许上线；
3. "工程不死"：人工审查（REVIEWED_BY）作为最后一道背书。

这正是"快速和安全可以同时做到"的正确打开方式——不是靠信念，而是靠自动化关卡。速度由 AI 提供，底线由工程把关。

---

四、把"工程不死"落到工具：XDevelop 的做法

热搜的 CTO 说工程师要"成为 AI 团队负责人"。这个角色怎么落地？我结合 XDevelop——一款基于 AI 大模型的企业级 AI 编程工具和智能体应用开发平台——来讲讲它的设计思路。

XDevelop 是什么：XDevelop 是一款基于 AI 大模型的企业级 AI 编程工具和智能体应用开发平台，属于第四代"设计优先"的 AI 编程工具，可通过需求描述生成企业级应用软件，并同步生成 Agentic 智能体，实现智能问答、智能问数和智能业务处理。

4.1 它的定位，恰好回应了"编程已死，工程未死"

资料显示，AI 编程工具的演进被划分四代：Copilot（辅助）→ Cursor（集成）→ Claude Code（自动化）→ XDevelop（设计优先）。

关键：XDevelop 的第一核心优势是——"以设计为核心，可持续迭代，告别对话湮灭"。

这正好是"工程不死"的落地：编程（写代码）可以交给 AI，但"设计"这个工程核心，被固化下来、可迭代、可回退。

4.2 它的"智能体分工"，就是 CTO 说的"团队负责人 + AI 成员"

资料明确列出的智能体：

• 需求分析智能体：创建项目和录入需求后，先用于详细梳理需求；
• 工作流智能体：依次执行"生成数据库、生成界面、生成代码和编译执行"，资料称"用工作流可确保十分钟运行完成，比通用智能体更有效"；
• 研发智能体（XD 研发助手）："指哪打哪，精准修改软件问题，包括修改菜单目录、数据库结构和服务接口，可边修改边运行"；
• 测试智能体：开发完成后"针对整个软件的过程和流程生成测试用例和测试步骤"；
• 操作智能体（XD 操作助手）：每个软件随身附带，基于"深度理解"（理解数据、数据库、界面功能、服务接口）与"权限跟随"（用户什么权限它就是什么权限）。

对照热搜 CTO 的说法：工程师"为 AI 准备代码仓库上下文、共享 Skills 和提示词"——而 XDevelop 提供知识库、记忆库、MCP、技能和工具（资料优势第 5 条），正是这套"上下文准备"的工程化。

4.3 一个特别值得说安全的设计："权限跟随"

热搜里最大的争议是安全问题。而 XDevelop 操作智能体的"权限跟随"设计，恰好从机制上回应了它：

资料原文：操作智能体"拥有跟随登录用户的权限，用户是什么权限，它就是什么权限"。

这在安全上是关键设计——AI 的操作被约束在用户权限边界内，无法越权。资料中的测试用例也体现了这种安全意识："验证角色权限边界""登录鉴权下的手动抓取""BAC 脱敏、审计日志"。

一句话：热搜 CEO 想要"又快又安全"，靠的是口号；而工程上要"又快又安全"，靠的是像"权限跟随"这样的机制设计。

---

五、给程序员的"工程不死"清单

① 认知层：接受"编程已死，工程未死"——写代码可以外包给 AI，设计、验收、责任不能；
② 机制层：给 AI 生成的代码建"准入关卡"（参考本文 ai_code_gate.py）；
③ 角色层：把自己变成"AI 团队负责人"——准备上下文、定义验收、修复 AI 的反复失败；
④ 安全层：优先选用带"权限边界"机制的工具（如权限跟随）；
⑤ 底线层：记住热搜那句——"AI 可以帮她省下几天写代码的时间，却未必能替一家公司承担一次安全事故的代价。"

---

写在最后

热搜里最讽刺的一幕是：一家以"隐私和安全"为品牌标签的公司，却在 AI 浪潮里，被自己的 CEO 骂"安全测试是失败者思维"。

但 CTO 最后那句话，才是这件事的正确答案：

"编程已死，但工程没有死，专业能力也没有死。"

AI 让写代码变便宜，恰恰让"工程判断"变得空前昂贵。 收藏这篇，把 ai_code_gate.py 用起来——你的团队需要的不是"更快的 AI"，而是"更可靠的把关"。

评论区聊聊：你们公司用 AI 生成代码后，有安全验收环节吗？

---