挑毛病太容易 - - 孩子的字写得歪、题算得慢。但鼓励有用得多：夸她今天完成了作业，她第二天还可能做到。这条三年前写的，依然是家里最管用的「配置」。对家人以鼓励为主，对五年后的自己以终为始，两件事都不靠聪明，靠天天做。

这一篇不聊职场，聊聊与家人相处之道。

书里讲"关注优点"那一段，我顺手把它用到了家里。

对家人，以鼓励为主

📖书里说：

我们碰到的比我们更优秀的人，哪个不是比我们更加勤奋？……我认为我们要更多地关注自己的优点。

✍️我的笔记（2023-04-28）：

对家里人以鼓励方式为主（是我之前做得不好的，也是我后续想要做好的！），发现并赞美她们做的好的、擅长做的，让她们变得更加自信！家庭氛围应该会更加好~

书里讲的是对己，我顺手把它用到了家里。挑毛病这事太容易了 - - 孩子的字写得歪、题算得慢，一眼就能看见。但鼓励有用得多：夸她今天完成了作业，她第二天可能还能做好。这条三年前写的，现在依然是家里最管用的一条"配置"。

模拟一下五年后

📖书里说：

我的人生中也曾充满很多艰难的"二选一"，后来我找到了一个有效的办法：以终为始，把眼光拉到足够远的未来，看看自己那时候的状态，如果喜欢那种状态，就坚持现在的生活，如果不喜欢那时候的状态，就立刻着手改变。

✍️我的笔记（2023-07-31）：

回想下自己，现在也有快乐和内心的满足，陪伴家人、和孩子一起玩耍、做菜、写文章、阅读、跑步，感觉很舒服。但是工作上起色不太大，没有承担更多的职责或创造的收益不大

这条笔记写得很平静，也很诚实：生活这边很舒服，工作那边"起色不太大"。按书里"以终为始"的办法推演五年后 - - 如果舒服的这部分继续，平淡的那部分也继续，我满意吗？答案是不满意。所以后来工作这边才有了那些折腾：带更大的摊子、把经验做成产品。舒服是留着的，平淡是被推走了。

写作，不挤占家里

📖书里说：

一定不要影响第一空间和第二空间 - - 第一空间是你的家庭，第二空间是你的工作场所。不要让第三空间影响你的家庭生活或工作。

✍️我的笔记（2023-07-13）：

我的写作不要影响日常工作开展，我的健身不要影响家里生活运转。

两行笔记，两道边界。爱好这事最容易翻车的地方不是坚持不下去，而是坚持得太猛，把工作和家庭挤了。晚上该陪娃陪娃，该睡觉睡觉，写作挪到碎片时间完成比如下班回到家、陪完娃和太太之后；运动放到早上早起后，周末留大块给家人。慢就慢点，业余选手拼的不是单日爆发，是十年总量。边界守得住，爱好才养得久 - - 也才养得住家。

写在最后：对家人以鼓励为主，对五年后的自己以终为始。这两件事，都不靠聪明，靠天天做。

说句实在的，我越来越多读纸质书：陪完娃、处理完安全事件，晚上想让眼睛歇歇，也从手机里抽身出来。这篇里提到的《人生护城河》，下面这张卡片就能买纸质版；书里关于家人的那几节我读了三遍，想自己读一遍、或者买本送家里人都方便。

想先免费读、或者习惯电子书的朋友，微信读书现在新用户有会员福利，搜书名就能读。顺带一句：你注册，我能攒点阅读天数，互不亏😄

这条笔记最打动我的，是“对家人以鼓励为主” - - 这点我在带团队、也在家里天天练。想在忙碌里给家人留时间、或者平衡工作和生活，也欢迎菜单「关于我-微信联系」找我聊聊。

跳转微信打开

安全建设最难的不是技术，是排序。而排序最好的依据，不是别人的最佳实践，是自己每一次被打穿的完整记录。

一、瓶颈不在“做什么”，在“排序”

安全行业不缺方法论。攻防矩阵、合规条款、厂商方案，随便一个都够读几百页。一个中等规模的安全团队，一个季度能列出来的待办事项通常有几十条。

真正的瓶颈，是另一件事：这些事，先做谁？

排序一旦失去依据，就会退化成几种替代方案 - - 谁喊得响谁先做、哪个合规条款先到期哪个先做、哪个产品正在推哪个先做、上一季度的整改计划改个日期变成这一季度的。这几种方式都能运转，但它们有一个共同缺陷：依据不来自我们身上真实发生过的事。

于是就有了那个循环：每年演练，每年复盘，每年在报告里写下“弱口令问题依然突出”、“安全意识有待加强”、“历史漏洞未及时修复”。

我们换了个思路：把每一次失守的完整记录，当作安全建设优先级的输入。

这条链上有六到七个独立问题，分属不同团队、不同系统、不同预算。如果复盘停在“加强访客管理”，其余问题一个都不会被处理。

这就是“事件解剖”要解决的事。

二、方法：一把尺子，三步走

整套方法只有三件事，但有一个前提：得先有一把尺子：一张能把任何一次失守，拆成结构化数据的固定表格。没有它，后面两步都做不了。

输入是四类东西：

处理分三步：

第一步　结构化拆解每个事件，按固定矩阵拆到可执行项

第二步　跨周期聚合归一化、去重、频次统计、盲区统计

第三步　生成建设清单措施生成 → 归类 → 排序 → 落归属

三步里，第一步决定后面两步能不能做。大部分复盘停在“写总结”，没有产生结构化数据，于是后面两步根本无从谈起。接下来三节，一节讲一步。

三、第一步：拆到可执行

我们用的矩阵，四个大类、十一个子类。每个子类都带一个判定问题，答“是”就落进这个格子。

这张表看起来像记录表，实际是一把尺子。它规定了每一份复盘必须回答哪些问题、必须拆到哪一层。【提示：文末提供原始复盘分析Excel表格！即是文中所言的尺子】

分类本身不重要，重要的是它必须：一个现象只能落进一个格子，否则跨周期聚合时无法对齐，第二步就废了。

三条硬约束

约束一：现象必须落到可执行项。

“钓鱼成功 39 人”不是问题点，是现象。往下拆：是终端未覆盖这批人，是覆盖了未检出，还是检出了策略未拦截？再往下：如果是未检出，是引擎能力问题，是样本用了白加黑绕过，还是规则库没有覆盖这类行为？一直拆到能对应上一个具体动作，才算拆完。

约束二：每个攻击招式，至少对应一个检测手段。

用来堵“知道了但没做”的口子。红队用过的招式，如果防守侧连一个能看见它的手段都没有，就显式标记为无检测覆盖。这类条目在后续排序中权重最高 - - 它意味着一个永久敞开的通道。

约束三：每个事件必须同时产出两个视角。

攻击方视角：哪些招式不常用但有效（说明攻击模拟的覆盖面不够，需要补测试用例）。

防守方视角：哪些招式反复使用且反复得手（说明排序排错了，或者根本没归属）。

一个拆解示例

一行现象，拆出三个可执行项，分属三个负责人：

如果只写“终端防护被绕过”，得到的是一个结论；拆开之后，得到的是三张可以派下去的工单。

四、第二步：让重复浮出来

单看一个季度，每个事件都不一样：有的是钓鱼，有的是未授权访问，有的是漏洞利用，有的是凭据泄露。把所有季度的问题点摊在一起，按子类归拢，重复会自己浮出来。

聚合有两个维度，缺一不可。

4.1 时间维度：哪些坑反复踩

我们把八个复发模式在各次演练中的出现情况标了出来：

这张图值得多看两眼：八个模式里，有五个在三次以上演练中出现过；其中“凭据散落”和“内网默认互信”各出现了五次。

而每一行横着看，都是在讲同一件事：这个问题大概率上一轮见过，写了整改，然后它又来了。

4.2 空间维度：哪些地方没人看

复发频次回答“哪些坑反复踩”，覆盖盲区回答“哪些地方从来没人看”。数据来自防护有效性专项验证：

这组数字里，最值得注意的是 25% 和 84.5% 的对比：已接入统一防护的那部分资产，能拦住 84.5% 的 Web 攻击——说明这项防护本身是有效的，问题出在覆盖率上。

这是一个很典型的判断错误：当防护效果不好的时候，第一反应往往是“产品不行，换一个”。但数据说的是“装得太少”，不是“产品不行”。

而40.3% 双盲意味着四成资产既没有防护、也没有检测 - - 它们不出现在任何告警里，不是因为没有攻击，是因为没人看。

五、第三步：排出优先级

有了重复，优先级就变成一道算术题，而不是一场辩论。

5.1 措施生成：一对一

每条不足对应一条加强措施，不允许含糊。“终端被致盲”对应的措施是“Agent 自保护机制建设 + 卸载与致盲行为独立告警”，不是“加强终端防护”。

一对一的好处是可验证：措施做完之后，能明确回答“这条不足现在还剩多少”。

5.2 归类到治理域

几百条措施最终收敛到十几个治理域：

互联网暴露面收敛　/ 安全产品自身安全基线　/　凭据与口令治理　/　检测能力提升（流量、主机、终端）　/　日志审计纵深　/　资产安全运营　/　敏感信息泄露监测　/　攻击面管理

5.3 排序：两个维度，一个加权项

两个维度分别是复发频次（该问题在几次演练中出现过）和影响半径（单点 / 单系统 / 跨系统 / 全域）。高频且大半径的直接进 P0。

另外有一个加权项：标记为“无检测覆盖”的招式，无论频次高低，一律上调。因为它意味着一个永久敞开的通道 - - 不是“可能会被打”，是“现在就能被打，而且我们看不见”。

5.4 每一项落三个字段

必须落：优先级 / 归属团队 / 依托平台。

这一步最容易被省，也最不能省。没有归属的措施等于没写，没有平台的措施会烂在表格里。

六、六次演练跑下来，数据说了什么

方法讲完了。但方法本身不说明任何问题 - - 真正有意思的是它跑出来的数字。把六次演练的复盘表摊在一起，得到的是这样一组数：94 个问题点，153 处维度确认，67 条不足。同期防守方记录在案的优点，13 条。

13 比 67。而且这 13 条里，大部分是“某个检测恰好起了作用”（钓鱼被拦、准入阻断），真正属于“我们主动发现了什么”的，只有两三条。

再看问题点落在哪里。这里面有三件事，跟我们事前的直觉不一样。

所以第一优先级该是什么？数据已经把答案写出来了。

1、凭据与口令治理

范围：默认口令强制更换、密码复用检测、凭据散落扫描（镜像、文档、代码、终端）。

2、检测体系失效本身

终端 Agent 被致盲、日志通道被切断、监控平台凭证可被伪造 - - 这三件事的共同点是：以为在监控，实际没有。

注意，这两项里没有一项是“买新设备”。它们全是“把已有的东西管好”。

如果这份清单是拍脑袋拍出来的，我也会心虚，但它不是。清单上的每一条，都能倒推回具体的事件编号和攻击路径。

七、AI 让这套方法可以每季度跑一次

前面三节讲的是方法。但方法有一个现实问题：它太重了，重到没人愿意坚持做。

一个季度几十个事件，每个事件要拆到十几个子类，拆完还要跨季度去重、统计频次、生成措施、归类、排序。这件事枯燥、重复、量大，而且恰好落在“重要但不紧急”的象限里 - - 每次演练完大家都很亢奋，一周之后就没人愿意再碰那张表了。

AI 在这里的作用不是替我们做分析，是让这套方法从“一个季度勉强做一次”变成“每个月度都能做”。

7.1 前提：AI 分析不了它看不懂的东西

把演练报告直接丢给模型，它会给一份读起来很顺的总结：“安全意识有待加强”、“检测能力需要完善”、“建议加强供应链管理”。

这些话放哪一年都对，也放哪一年都没用 - - 因为它没有结构，只是在复述原文。让这件事跑起来的不是模型，是那把尺子。

7.2 从五天到两分钟，让复杂的事可以常态做

框架做完之后，我手工做了第一份分析：一个季度的事件，逐条拆到可执行项，大概花了 五天（期间有其他事情穿插着做）。做完之后我意识到：这五天里最值钱的不是那份分析，是那把尺子。

把框架交给模型，让它按同样的结构去读每一份演练报告、每一份验证结果，逐条抽取，再按框架生成结论与启发。现在一份 2 分钟。

五天到两分钟，这个差距不是“提效 30%”那种差距，是“这件事以前一个季度只能做一次，现在每个月度都能做、甚至每一起事件都能做”的差距。

7.3 把“尺子”写成机器可执行的规格

人脑里的分类和机器能执行的分类，不是一回事。“安全防护”这四个字，人一看就懂；机器拿到它，不知道边界在哪。

要让 AI 稳定输出，每个子类必须带一个排他性判定问题 - - 答“是”就落进这个格子，答“否”就往下走。

id: ENDPOINT_SELF_PROTECT
category: 安全防护
question: Agent 被卸载、停止或致盲时，是否存在独立于 Agent 自身的告警？
exclusive: true
action_hint: Agent 自保护机制、看门狗进程、独立上报通道

三个设计要点：

• 枚举，不是自由文本。子类必须是闭合集合。模型可以新增候选子类，但不能直接写进结果——新子类要人工评审后入枚举，否则跨季度无法对齐。

• 判定问题必须排他。一个现象只能命中一个格子。我们最早的一版有重叠（“未鉴权访问”同时可以归到“安全设计”和“运维管理”），聚合阶段就崩了。

• 带上 action_hint。子类对应的大致处置方向。它不直接进清单，但能大幅提高模型生成措施时的命中率。

7.4 抽取分两遍，不要一次做完

最开始的提示词是“按矩阵分析这份报告，输出全部字段”。结果是：输出很好看，但细节丢得厉害 - - 模型会在“归纳”这一步把具体的技术动作合并掉，只剩下一句“攻击者利用弱口令横向移动”。

拆成两遍之后稳定很多。第一遍只抽问题点，不做任何归纳，要求保留原文的表述粒度，宁可拆碎；第二遍再逐条归类，并生成对应不足与加强措施。

为什么必须分两遍？：抽取和归纳是两种不同的任务。混在一起做，模型会优先满足“让输出好看”，而牺牲掉“把细节留住” - - 而细节恰恰是后面所有步骤的原料。

同时有一条硬要求：每条判断必须回填原文证据。

{
"finding": "使用企业IM机器人发送钓鱼消息卡片，点击后浏览器自动下载样本，最终 29 台终端上线",
"subcategory": "检测能力",
"gap": "终端对 IM 渠道投递的样本无检出能力",
"evidence": "共上线39人",
"action": "补充 IM 渠道投递类样本的检测规则"
}

证据字段有两个作用：一是人复核时不用回头翻原报告，二是它是校验幻觉的唯一切口。

7.5 输出必须过校验，不能直接采信

这一步不能省。不加校验的自动化，产出的是一份看起来很完整、实际上无法用于统计的数据——比不做更危险，因为它会让你以为已经做完了。

7.6 归一化：让不同季度的同一件事对上

这一步最容易被低估，也最难。同一个问题，在不同季度的报告里表述完全不同：

按原文做频次统计，这三组会被算成 8 个独立问题，各出现一次；归一之后，它们是 3 个问题，各出现 2-3 次。

8 个一次性问题，和 3 个反复出现的问题，在排序上完全是两个结论。

我的做法是给每个复发模式一个稳定 ID，把定性的观察变成“标签 + 计数”：

CRED_DEFAULT　默认口令未更换
CRED_REUSE　口令复用（服务器 / 域 / 应用）
CRED_SCATTER　凭据散落（镜像、文档、代码、终端）
ENDPOINT_TAMPER　终端 Agent 被卸载 / 致盲
PATCH_STALE　历史漏洞未修复
IMPLICIT_TRUST　内网默认互信 / 未鉴权访问
TOKEN_FORGE　身份令牌可伪造
LOG_SINGLE　日志通道单一且可被切断

有了稳定 ID，频次统计就退化成一次 group by，跨季度对齐不再依赖谁的记忆更好。有两个工程约束必须守住：

• 标签由人命名。模型可以提“疑似新模式”，但 ID 必须人工确认后入库。放任模型自由命名，同一件事会在一百份报告里长出一百个名字。

• 映射表要随分析一起迭代。新标签入库后，历史数据要回标一遍，否则频次会被截断。

7.7 输入输出规格

完整的字段规格（输入、框架、输出、后处理、可复算性），我放进了文末获取的模板里，单独一个工作表，方便直接对着改。

这里只说一句最要紧的：框架是会改的。每次改矩阵，都要记版本号，并把历史分析按新版本重跑一遍 - - 否则手里会同时存在几套不可比的数据。

7.8 边界：AI 做什么，不做什么

省下来的是重复的体力，不是判断。AI 初稿的归类会错，归因有时停在现象层，偶尔会漏掉整个维度，这些都要人审。工作量没有消失，只是换了个位置 - - 人从搬砖的，变成质检的。

三件事不交给模型：

• 归因的准确性。“为什么没检出” - - 是引擎能力问题、策略配置问题，还是样本本身在白名单里，三种答案对应完全不同的动作。模型给出的归因看起来很合理，但它不在现场，不知道我们上周刚改过策略。

• 优先级背后的权衡。技术上的第一优先级，可能因为业务窗口期、人力、跨部门现实需要后移。取舍是人做的，也必须有人负责。

• 责任的归属。这条措施归谁，不是模型能决定的，需要人根据实际职责分工来做出判断。

顺序不能反：先有框架，再有 AI。框架是人想清楚的，复制是机器干的。人省下来的是重复劳动，换来的应该是更长的复核时间和更厚的判断。

八、沉淀下来的几条判断

方法之外，把拆事件拆出来的、最通用的判断放在这里。每一条后面都有一次真实的失守。

1. 安全产品自身往往是最危险的入口。它能直连内网、有高权限、常年不更新、漏洞没人敢报。

2. 防不住卸载的终端防护等于没装。一个能被普通权限干掉、且干掉之后没人知道的 Agent，提供的是虚假的安全感。

3. “内网 = 可信”是所有失守的共同前提。攻击者在内网拿到的每一样东西，都是我们自己放在那儿的。

4. 凭据是攻击链上的硬通货。复用、明文、浏览器保存、镜像残留、离职未回收——攻击者不需要多聪明，他只需要比你先找到。

5. 默认口令出现一次是疏忽，反复出现是治理失能。

6. 监控系统本身不能是被绕过的那一个。一个令牌可被伪造的平台，它发出的每一条告警都值得怀疑，包括“一切正常”。

7. 单一日志通道一定会被切断，第二条独立采集路径不是冗余，是视力。

8. 漏洞不修，就是把上一季度的失败存进下一季度。

九、结语

回到最开始那个“前台开门”的攻防演练。现在回头看，那是这几年里最有价值的一次演练 - - 不是因为它暴露了物理安全的漏洞，而是因为它逼着我们把一台没锁屏的电脑，一路拆到了 CI/CD 的凭据管理。

从“前台不该随便放人”，到“凭据不该散落在镜像和文档里”，中间隔了七八个归因层级。大多数复盘，停在了第一层。而第一层的结论，通常是最没用的那一层 - -因为第一层的结论，往往是“某个人的问题”，而不是“某个体系的问题”。

这也是那份数据想说的：“人的问题”只占 14.4%。剩下 85.6%，是我们自己可以动手改的东西。

所以别把复盘报告存进档案室。把它们摊开，一条一条拆。这一步没人能省 - - 得先自己动手拆出一份，哪怕花上五天。因为这五天里真正值钱的，是手里那把尺子。

尺子做出来之后，剩下的事可以交给 AI：归类、去重、数频次。让它告诉哪些坑，已经掉进去过很多次了。那份清单，就是接下来的建设计划。

跳转微信打开

做管理最舒服也最危险的事，就是慢慢只开会、只拍板，手离键盘越来越远。我给自己立了死规矩 - - 攻防演练看细节，最难的那部分方案自己写。管理的底气，一半来自职位，另一半来自"随时能自己上"。

接上一篇。这一篇写带人。从19年北漂开始，陆续开始组建并壮大团队，最多的时候加起来实线有30来人，书里讲管理的段落被我画得最密。

梯队，一定要建

📖书里说：

梯队无论如何一定要建，而且要非常强。梯队里的每个关键角色一定要能弥补你的短板，在某方面要超过你。

✍️我的笔记（2023-07-11）：

TL一定是有一技之长，还要心态open，打造团队梯队，招其他方面比自己强的人，集人之所长一起战斗！

"招比自己强的人" - - 这话谁都会说，做起来最难。招一个某方面不如自己的人，心里踏实；招一个全面超过自己的，会有危机感。我花了很久才跨过这道坎，想通的契机很简单：管理者的产出是团队的产出，下属个个强，团队才能打硬仗。在高手如云的团队中，能够hold住大家，带着大家拿下一个个项目和战役，做长期有远见的工作规划，提前识别并处置潜在的安全隐患，这也是硬本事。

用人，就要用人的好

📖书里说：

用人就要用人的好，总是盯着他的不好，他能好才怪。我愿意招聘并且重用的人，都是有突出优点而缺点我能接受的人。

✍️我的笔记（2023-07-16）：

这个观点好理解，但是结合现状来看，团队内部可以接替我的人存在比较明显的管理短板。这点让我比较累，不过我也转向有意识地去找机会锻炼他们，尤其是有意愿参与锻炼的人。

这条笔记写得很诚实：道理都懂，但一到自己团队就变成"盯着短板补短板"。带人这几年我慢慢学会分辨 - - 有的短板是致命的（比如诚信、不开窍），不能用；有的短板只是不熟练，扔给他一个项目练一练就有了。把"补短板"当成唯一手段，等于永远在修理，没人往前冲。

经理要有一技之长

📖书里说：

怎样确保自己的工作安全？第一，自己一定要有一技之长……你至少要有一技之长，是可以脱离他人独立完成的。第二，要展现更大的影响力，别和下属较高低，要去更大的组织里替团队拓展空间。

✍️我的笔记（2023-07-11）：

简单来说，就是要有专长，做到一定范围无人能替，重大项目中要能独立承担一部分工作。

禁止脱离一线！！

增强实战能力！！

四个感叹号，是我全书喊得最用力的一条。做管理最舒服也最危险的事，就是慢慢只开会、只评审、只拍板 - - 手离挖洞、渗透、研究专业技术越来越远。我给自己立的规矩就是这六个字：禁止脱离一线。攻防演练我还是要看细节，方案我还是自己参与写最难的那部分。管理的底气，一半来自职位，另一半来自"随时能自己上"。

任何人，都要可以被替代

📖书里说：

从任何公司、雇主的角度出发，任何人都要可以被替代才行。因为有志之人迟早要做自己的公司，自己做自己的雇主，所以要尽早有这个心态，而不是抵抗。

✍️我的笔记（2023-07-11）：

有志之士迟早要做自己的公司，这句话是发自肺腑的吗？目前我还只意识到成为无可替代的一员，还没想那么多。

当时我在这条后面打了个问号：员工追求"无可替代"，公司要求"人人可替代"，这两句放在一起打架吗？三年后我想通了：不打架。"无可替代"是个人价值，"可以被替代"是备份 - - 把自己备份好（梯队、文档、方法论），才腾得出手去做更值钱的事。死守着一个坑不让人碰，那不是护城河，是把自己砌进了墙里。尤其是在人年轻的时候，嘴里叫着OPEN，心里和行动也要有魄力跟得上。

120条想法，这是第二篇。后面还想聊聊家人、还有"呆得太爽了就会有问题"，接着写。

跳转微信打开

SDL 推不动、团队留不住人、要不要转 AI——挑 2 个人聊聊，99 元，10 月 10 日截止。

做安全这十几年、公众号近九年，后台、私信及微信聊天里，反复出现三类对话：

• 想做SDL或做了一段时间，文档、工具、同行最佳实践和方法论准备了很多，但进度和效果不明显，于是开始怀疑自己这套方法本身有问题；

• 开始接手技术团队管理，团队五六个人，活一直在干，年底述职的时候却说不出安全到底防住了什么；想招人招不来，想留人留不住；

• 干了七八年甚至更久的安全，看着身边的人往AI 方向转，也在想自己要不要动、往哪儿动，问了一圈，答案都像正确的废话。

这三件事我都经历过，也都折腾过。它们看着不一样，卡住的往往不仅是技术问题。所以我开了咨询服务，做了三件事：SDL 怎么在一个企业环境里跑起来、安全团队怎么带、安全人自己怎么成长。

之前把这三块做成了咨询服务（菜单"关于我 → 咨询服务"能看到）。但说实话，挂了一阵子，主动来问的人不多。

我复盘了一下，问题大概在 - - 没把"我能解决什么、适合谁、怎么协作"讲清楚。这次换个做法：开放 2 个咨询位，99 元/次，约 60 分钟，微信语音或视频。

先说清楚三件事：

第一，这是面向个人的，不接企业项目。我不替谁的公司出方案，也不做乙方交付。你带着你眼下的难题来，我陪你这个人把它走过去 - - 你最后拿走的是你自己的判断，不是一份盖了我名字的 PPT。

第二，结束时你手上会有东西：不是一段聊天，是一份针对你这个场景的东西 - - 你的卡点到底在哪一层、下一步先动哪几件事、这件事该去找谁谈。能不能落地取决于你，但至少你不用从零开始想。

第三，不是谁都能约。我会请你先答四个问题（写满 50 字那种），我根据回答决定这次聊不聊得动；没接的，我会告诉你原因，不会让你干等。

另外一件必须提前说的事：聊完之后，我会把它整理成一篇脱敏案例发在公众号上 - - 发之前会先给你看，可以匿名、可以改，你不同意我就不发。这也是我这次想到底验证的一件事：这些方法换一个人、换一个环境，还成不成立。

怎么报名：

公众号后台回复「咨询」两个字，会收到那四个问题。填完发回给我（私信和微信均可）就行。

报名截止：

10 月 10 号。

关于价格：

99 元不是目的。它是让我能确定对面是一个真有问题、而且愿意花时间把问题讲清楚的人。同时是实验价，不是常态价。正式服务分三档（SDL 陪跑 / 团队管理 / 个人发展），价格和内容在菜单"咨询服务"里能看到 - - 这次开放的 2 个位置，是里面的入门形态。

跳转微信打开

焦虑像白纸上的黑点，越盯越黑。我把三年前租房、孩子上学那些消耗，连同书里的提醒，拼成一套「安全事件式」应对法：感知黑点 → 写下来理清 → 挖问题背后的问题 → 缩短消极窗口。漏洞修不掉全部，但可以管理；焦虑也一样。

从今天开始，分享第二本书 - - 辉哥的《人生护城河》，这是我最喜欢的一本书之一，亦是我做笔记最多的一本书。这本书我读了不下三遍，微信读书一遍，纸质书两遍，现在不时还会拿出来翻。

第一篇想写焦虑，虽然白天被强大的理性和诸多事情驱动，察觉不到，但有时似乎会通过梦境体现出来。2023年夏天那几个月，我的笔记里全是这个主题 - - 那阵子被租房、孩子上学这些事缠着，人很消耗。书里两段被我拆成了两篇，其实是一件事的上下集：黑点冒出来，然后怎么跟它过招。

白纸上的黑点

📖书里说：

一旦碰到焦虑，我能很明显地感知，并且能让自己接纳这种焦虑……但是一旦你可以跳出自己的躯壳，漂浮在空中，看着有一些焦虑的自己，反倒没有那么可怕了。

✍️我的笔记（2023-07-24）：

焦虑的事儿，就好似白纸上的一个小黑点，深陷其中就觉得满世界都是难受……感觉主动接纳焦虑并想办法解决（一般还是因为问题引发的），才是最好的办法，与此同时去挖掘问题背后的问题，拉长时间来看待问题

焦虑像白纸上的一个黑点 - - 盯着黑点看，满世界都是黑的；把视线拉远，它就是一张大白纸上的一个点。我后来处理焦虑就照这三步：接纳、挖问题背后的问题、拉长时间线。跟处理安全事件一个套路：先止血，再查根因，最后做长期加固。

写下来，烦恼就不在心里了

📖书里说：

……当我开始这一天尴尬的写作之后没多久，神奇的事情发生了：我内心的愤怒、不平，逐渐在写作的时候释然了。

✍️我的笔记（2023-07-25）：

太相似了，有问题困扰的时候我也很喜欢写写画画，好似写下来、烦恼就不在心里似的。其实应该是帮助我理清了思路

"好似写下来、烦恼就不在心里似的" - - 写的时候以为是心理作用，后来明白了：写作强迫你把一团乱麻拆成一条一条的句子，拆完思路就清了。思路一清，能动手解决的就动手，动手不了的就搁置，焦虑自动少一半。我每天复盘，一半功能就是这个。

问题背后的问题

📖书里说：

任何不能毁灭你的，都是具体的困难，只不过给你提供了深刻思考的机会，让你有机会解决更长期和更广泛的问题。

✍️我的笔记（2023-07-16）：

最近确实被一些事儿缠绕着，消耗了很多心力。比如： 1、租房问题 2、孩子上学 3、空调问题 4、书柜问题… 问题背后的问题是：敲定未来的生活城市？

这条笔记很有代表性：表面上列了四件烦心事，往深挖一层，四件事其实是同一件事 - - 定在哪座城市生活。焦虑最耗人的地方就是它的包装方式：把一个大问题拆成无数个小麻烦，让你逐个应付、永远在应付。把问题背后的问题挖出来，虽然答案未必马上有，但至少从"打地鼠"变成了"打 boss"。三年后回看，那张清单上的一项项都有了着落 - - 孩子都该升二年级了。城市这个 boss，后来也就那么打过去了。

错误和意外，是信号

📖书里说：

我们所谓的错误与意外，其实就是生命这个黑盒子给你的信号，你应该通过这个信号去获取更深层次的东西。

✍️我的笔记（2023-07-16）：

错误与意外，我们不可能遇不到，但是可以正视它，积极主动正向的去解决或提早筹划

干安全的看这段，应该会有职业既视感：事故就是信号，信号指向系统的缺陷。个人生活也一样 - - 总在同一个地方出问题，就不是运气问题了。我的原则是同一类意外出现第二次，就必须停下来查根因，而不是第三次凭运气。提早筹划也是本行的职业病：预案都是提前写的，等出网络安全事故再写就不叫预案了。

缩短消极的时间窗口

📖书里说（李想）：

"对外关注探索，就不那么烦躁；对内关注成长，就不那么焦虑。但是，烦躁和焦虑都是永远发生的，我们要做的是减少时间周期。"

✍️我的笔记（2023-07-16）：

好句子、好观点……把控大局，缩短消极影响自己的时间窗口

这段话最治愈我的地方是它不承诺消灭焦虑 - - 焦虑永远在，能管理的只有它霸占你的时长。以前一件糟心事能让我低效三天，后来是一天，现在争取压到当晚。跑步是我压缩窗口最有效的手段：三公里下来，事情还在，但情绪的潮水退了，能看见滩涂上的路了。时长就是成本，焦虑超时，才是焦虑真正的伤害。

给自己设个底线

📖书里说：

你平时有多少力气花在了内部竞争上……如果这一切都来源于自己过多的无处安放的欲望，那么内心平静之道就在于自身。

✍️我的笔记（2023-07-24）：

1、要防止自我妥协，设置底线应该可以保住；

2、自己在控制焦虑这件事儿上做得还不够好……多加锤炼吧

放最后这条，因为它最诚实：我在控制焦虑上做得不够好。盘算好了"想到某个程度就不想了"，结果还是控制不住地想。我的补救办法就两条：一是设底线 - - 焦虑允许存在，但不许占用行动时间，到点该跑步跑步、该写稿写稿；二是把力气从"内部竞争"里抽出来，投到自己的长板上。焦虑管不住，但注意力的去向，勉强管得住。多加锤炼吧 - - 这句原话留着，共勉。

写在最后：这七段连起来，正好是安全事件响应的流程：感知（黑点）→ 记录理清（写下来）→ 挖根因（问题背后的问题）→ 缩短窗口。焦虑跟漏洞一样，修不掉全部，但可以管理。

跳转微信打开

漏洞预警的瓶颈从来不是"不知道有漏洞"，而是从通告到确认受影响的转化。本文分享AI驱动的"监测→内化→应用→验证"四阶段闭环实践，以及CVE-2026-42945排查脚本从能跑到敢在上万台机器上跑的三轮迭代。关键认知：AI备好判断输入、落成执行动作。

漏洞预警真正的瓶颈，从来不是"不知道有漏洞"，而是从看到通告到确认自己受影响之间那段转化。

这篇文章基于两个已经落地的成果展开：一张《漏洞预警流程 - - AI 驱动四阶段闭环体系》流程图，和一份针对 Nginx CVE-2026-42945 的批量排查脚本（迭代到 v1.0.2）。前者是体系流程，后者是流程里"应用"环节被真正跑起来的一个切片。

数据速览

先把全篇要用到的数字摆出来，后面每一节都在解释它们是怎么来的：

对象 → 规模

一漏洞预警的瓶颈，从来不在"信息"

做安全的人都有一个共同感受：漏洞信息永远是过量的。

奇安信 CERT、CVE / NVD、微软安全公告、Chrome 安全更新，再加上各种商业与开源情报源，每天推过来的通告数以百计。真正稀缺的从来不是"漏洞线索"，而是三样东西：

1. 判断力

   ——这个漏洞对我方资产到底成不成立？

2. 时间

   ——从看到通告到确认影响范围，能不能压缩到小时级？

3. 一致性

   ——同一个人、不同时间、面对不同漏洞，能不能给出同样质量的结论？

传统做法是"人工盯 + 人工查"：信息靠人刷，判断靠经验，排查靠临时写命令。结果是监测环节堆满了信息，内化环节堵在了一个人身上，应用环节的排查动作又高度重复、质量参差。

我们先把场景盘清楚了，才敢谈 AI

在动手做任何自动化之前，我先做了一件事：把 AI 可能介入的安全业务场景全部列出来，形成一张全景图。结论是 7 类：

这七类场景有一个共同的形状：前端是海量、非结构化的信息，后端是可以标准化的动作。这个形状恰好就是 AI 最擅长补位的地方 - - 读得比人快，记得比人全，但判断必须由人兜底。

本文聚焦第一类，也是我们打磨最久的一类：漏洞预警。

二流程：AI 驱动的四阶段闭环

我们把漏洞预警拆成了四个阶段：监测 → 内化 → 应用 → 验证。

图 1：漏洞预警流程 - - AI 驱动四阶段闭环体系（监测 → 内化 → 应用 → 验证）

先把全局看清，再逐个阶段展开：

① 监测：信源聚合与降噪

渠道是固定的五类：奇安信 CERT、CVE / NVD、微软安全公告、Chrome 安全更新，以及微信公众号开源情报源。

这一步 AI 的价值不在"抓取"（抓取是工程问题），而在降噪和初筛：同一漏洞被多个渠道重复推送时去重、把与我们技术栈无关的通告降权、把"影响面大且可落地"的通告前置。人不再需要逐条读完全部通告，只需要读被排到前面的那几条。

② 内化：把通告翻译成"可判断的结论"

这是整个流程里最关键、也最难的一环，流程图上专门用红字标注了：需要人工参与。内化要产出四样东西：

• 漏洞原理：它到底是怎么触发的；
• 漏洞细节：触发它需要满足哪些前置条件；
• POC 代码的提取与分析：有没有可验证的 PoC，PoC 说明了什么；
• 是否启动应急响应的判断。

AI 在这里承担的是"重活中的体力活"：通读公告与 PoC、把散落在正文/附件/引用链接里的利用条件结构化地抽出来（版本区间、配置要求、认证前提、是否需要特定编译选项），并给出一个初步研判。

而人承担的是"重活中的判断活"：是否启动应急响应的标准是什么。这是流程图里反复强调、也是我们至今仍在持续明确的问题——这个标准不能交给模型去猜。

一个关键认知：AI 不是把"研判"这个环节自动化掉了，而是把研判的输入准备好了。以前研判的人要花两小时读材料，现在读一份已经被整理好的结论摘要，再把时间花在真正需要经验的那一步。

③ 应用：三个团队并行，11 个动作节点

这是流程里最"重"的一段，也是最容易被 AI 提效的一段。三个团队并行推进，各自面向不同的资产面：

三支队伍的差异，其实在"用什么工具去确认范围"这一句上：

安全运营团队（全域网络资产）

1. 受影响范围初评：查询 CAASM 平台 / 联动 OPS，通过名称、版本信息初步判断可能受影响的资产；
2. 受影响范围确定：使用 CAASM 平台 / 联动 OPS，通过 POC 扫描、主机信息收集确定实际受影响范围，并针对性输出防御或检测方法；
3. 推动受影响修复：通过 CAASM 平台工单、POC 扫描结果生成工单，推送给资产责任人，提醒按 SLA 修复；
4. 修复后验证：再次通过 POC 扫描、主机信息收集验证修复情况。

内部蓝军团队（面向"打不打得进来"）

1. 漏洞分析与研判：分析和复现漏洞，输出利用条件、难易程度、POC，以及是否启动应急响应；
2. 漏洞利用武器化：直接或结合历史漏洞，做成实战渗透的武器；
3. 丰富 BAS 用例库：转化为 BAS 格式的验证 POC，加入常态化安全有效性验证。

产品安全团队（面向产品线）

1. 受影响范围初评：查询 SDL 平台组件及工单，通过名称、版本信息初步判断可能受影响的资产；
2. 受影响范围确定：使用 CAASM 平台 / 组织产线安全专员，通过漏洞利用条件、POC 等确定实际受影响范围；
3. 推动受影响修复：通过 wiki / SDL 平台创建漏洞工单，推送给产品安全专员，提醒按 SLA 修复；
4. 修复后验证：使用检查配置、POC 等方式验证修复情况。

流程图上还压着 4 条 PS 备注，它们恰恰是"纸面流程"和"真实流程"的差距所在：

• 暂无 POC 等无法用 POC 直接验证的场景，先用人工跟进全流程闭环；

• 需关注安全产品检测规则更新、或自研检测规则更新；

• 外部客户侧的修复需视实际情况而定，影响大、舆论声音大走 PSIRT 流程；

• 需关注实验局中安全产品的自身安全情况。

AI 在"应用"环节的落点，就是把内化阶段产出的"利用条件"，直接变成可在资产上批量执行的排查动作。下一节的脚本，就是这一段的具体实现。

④ 验证：闭环，以及回退

验证有三层：

1. 各细分场景 / 团队验证对应的漏洞修复情况；

2. BAS 验证新漏洞的安全防护（监测）效果；

3. 验证通过 → 闭环；不通过 → 回退到修复阶段。

注意第 3 条——流程里明确写了回退路径。一个没有回退的流程，闭环是假的。

同时有一个容易被忽略的 PS：需关注安全产品检测规则更新，或自研检测规则更新。 一个漏洞的闭环，不只意味着"资产修好了"，还意味着"我们下次能不能更早发现它"。

三案例：CVE-2026-42945 排查脚本是怎么迭代出来的

流程讲完，来看一个真实切片——一份 153 行的 Nginx 批量排查脚本，从能跑，到敢在上万台机器上跑。

图 2：把通告里的自然语言翻译成判定逻辑 —— 三条件联合判定 + 4 步检测

3.1 从"通告"到"判定条件"：一次翻译

通告给出的信息是描述性的：某版本区间的 Nginx，在特定 rewrite 配置下，叠加 ASLR 关闭的环境，存在可利用风险。

人类读这段话，会立刻明白"要同时满足三个条件才真正有风险"。但要把它变成机器能跑的逻辑，需要一次翻译：

通告里的自然语言 → 翻译成的可执行判定

这一步就是 AI 最直接的用武之地：把通告读成条件表，再把条件表写成代码。 人只需要复核条件表对不对——复核一张表，比复核 153 行代码便宜得多。

3.2 脚本长什么样：4 步检测

翻译完条件，脚本的结构几乎是自然浮现的：

值得注意的是：判定逻辑（版本区间 + 配置匹配 + ASLR）在宿主机和容器两条路径上是同一套，只是执行方式从本机命令换成了 docker exec。逻辑复用，才能保证两个环境的结论可比。

3.3 版本区间判定：一个典型"看起来简单"的坑

第一版最容易写错的就是版本比较。字符串比较会把 1.9.0 判定为大于 1.30.0，直接导致漏报。最终采用的是 sort -V 的版本序比较：

LOW_VER="0.6.27" HIGH_VER="1.30.0" IN_RANGE=0  if [[ $(echo -e "$VER\n$LOW_VER" | sort -V | head -n1) == "$LOW_VER" && \       $(echo -e "$VER\n$HIGH_VER" | sort -V | tail -n1) == "$HIGH_VER" ]]; then     IN_RANGE=1     echo "   → 版本落在漏洞影响区间" else     echo "   → 版本不在漏洞区间，安全" fi

逻辑是：把目标版本和上下界一起排序，如果目标版本排序后既不小于下界、又不大于上界，就落在区间内。

这类"边界条件"是 AI 辅助写脚本时最该被要求穷举的部分——六个用例一次列全：正常版本、区间下界、区间上界、比下界小、比上界大、多段版本号（如 1.9.0 vs 1.30.0）。

3.4 v1.0.2：三个被真实环境打出来的问题

脚本头部留了一行版本说明，很能说明问题：

# 版本：v1.0.2 修复空配置误判文案、日志/tmp无权限问题、宿主机+容器全覆盖

三个修复，对应三类典型的"在实验室里想不到、一上生产就暴露"的问题。

问题一：空配置被误判为"有风险"。

早期版本里，grep 没匹配到内容时返回空，脚本却依然打印了"发现高危配置"，制造了误报。修复方式是先判空，再下结论：

CONF_DETAIL=$(grep -rE 'rewrite.*\?.*\$[1-9]' \     /etc/nginx/ /usr/local/nginx/ 2>/dev/null | grep '\.conf') if [ -z "$CONF_DETAIL" ]; then     echo "无高危配置" else     echo "发现高危配置"     echo "$CONF_DETAIL"     [ "$ASLR" -eq 0 ] && RISK=1 fi

注意这里还藏着第二个细节：只有当"配置命中"和"ASLR 关闭"同时成立时才置风险位，而不是看到配置就报风险。这是对"三条件联合判定"的忠实实现——流程的严谨性，最终要靠代码的严谨性来承载。

问题二：日志写不进去。

早期把日志写在工作目录，遇到权限受限的机器直接 Permission denied，整个排查中断。改为写 /tmp 并同时输出到终端：

LOGFILE="/tmp/nginx_scan_$(hostname)_$(date +%Y%m%d%H%M%S).log" exec > >(tee -a "$LOGFILE") 2>&1

日志文件名里带上主机名和时间戳，是为了多台机器并发执行后，回收日志时不会互相覆盖——这是一个"批量执行"场景才会浮现的需求，单机测试永远遇不到。

问题三：只查了宿主机，漏了容器。

这是最致命的一类遗漏。现在很多服务跑在容器里，宿主机上根本没有 nginx 命令，脚本会直接输出"宿主机未安装 Nginx"然后收尾，看起来一切正常，实际风险全在容器里。

修复后的脚本做了两件事。一是自动兼容 sudo docker：

DOCKER_CMD="docker" if ! docker ps &>/dev/null; then     echo "[INFO] 当前用户无docker权限，尝试sudo..."     if sudo docker ps &>/dev/null; then         DOCKER_CMD="sudo docker"     else         echo "[WARN] 无Docker权限，跳过容器检测"         DOCKER_CMD=""     fi fi

二是遍历所有运行中容器，对每个容器重复同一套"版本区间 + 高危配置"判定，把宿主机和容器的结论合并到同一个风险位上。同时，无 Docker 的场景下走一条干净的收尾分支，直接给出结论，而不是让脚本在半路报错。

最终输出被收敛成一句话，让非脚本作者也能直接读结论：

⚠️  【有风险】存在：版本命中 + 高危rewrite配置 + ASLR关闭 ；✅  【安全】所有宿主机/容器Nginx均不满足全部漏洞利用条件

3.5 复盘：AI 做了什么，人做了什么

回头看，AI 在这份脚本上的贡献可以拆成四件很具体的事：

分工非常清楚：AI 负责把条件变成代码，人负责确认条件本身是对的。

四方法论：给自动化定级，别用最高那一环代表整体

有了流程，还差一个坐标系：这套东西到底自动化到了什么程度？ 我们用一个四级模型来定位。

4.1 四级成熟度

图 3：自动化成熟度分级 —— 排查脚本在 L2，内化研判仍在 L0

4.2 本案例的位置：一个流程，三种级别

把前面两个成果放进这个坐标系，会发现一件有意思的事——同一个流程里，不同环节的成熟度并不一样：

所以最重要的一句话是：整体成熟度由最低的那一环决定。 排查做到了 L2，不代表漏洞预警做到了 L2 - - 木桶的短板仍然卡在"是否启动应急响应"那一步。

这也是我们不去宣传"漏洞预警已实现自动化"的原因：局部 L2 是事实，整体 L2 是夸大。

4.3 什么时候可以升级

往上升一级之前，先回答三个问题：

自检问题 → 答案是"否"时该怎么办

对照本案例：判定条件能枚举（版本 + 配置 + ASLR 三个条件）；错了的代价可控（脚本只出结论，不自动处置）；有回退路径（验证不通过退回修复）。三个条件都满足，所以排查环节做到 L2 是合适的。

而"是否启动应急响应"这一环，恰恰卡在第一个问题上——标准还没定义清楚，条件就枚举不完，所以它只能留在 L0。 这不是技术能力不够，是业务判断还没收敛。

五沉淀：AI 的 5 个可复用能力，和 4 条不能越的边界

把上面的流程和案例抽象一层，AI 在漏洞预警中稳定的价值点有五个：

1. 信息抽取

   ——从通告、PoC、情报里抽取版本区间、前置条件、IOC、TTPs 等结构化字段；

2. 条件翻译

   ——把"利用条件"翻译成可执行的检测逻辑，这是从"内化"到"应用"的关键一跳；

3. 代码生成

   ——批量排查脚本、扫描规则、BAS 用例的初稿生成；

4. 边界自检

   ——主动穷举空值、异常版本、权限缺失、环境差异等分支，这是最容易被人类作者忽略的部分；

5. 批量落地

   ——同一份逻辑同时覆盖宿主机与容器、同时适配多台机器，把一次性排查变成可复用工具。

对应的，也有必须守住的边界：

• 应急响应的启动标准必须由人定义，不能由模型推断，否则流程会失去一致性；
• 模型可能给出似是而非的 CVE 编号、版本号、PoC 细节，所有事实性内容必须回到官方公告核对；
• 版本比较、区间判定这类"看起来简单"的逻辑，恰恰是误报漏报的高发区，必须用真实数据回归验证；
• 暂无 POC、或像微软这类无法用 POC 直接验证的场景，仍以人工跟进全流程闭环为主——这是流程图上明确写下的 PS。

六这套方法能迁移到另外 6 类场景吗

能，而且迁移成本比想象中低 - - 因为 7 类场景共享同一个骨架：监测 → 内化 → 应用 → 验证，变的只是"内化阶段要产出哪些字段"。

只要"内化"这一步能把非结构化信息压成固定字段，"应用"和"验证"就能被标准化。 这也是我们坚持先把漏洞预警这一类做扎实的原因 - - 它是这套骨架最完整的样本。

七落地清单：如果你也要做，先做这 11 件事

1. 信源先固定（5 类足够），先解决去重与排序，别急着上模型；

2. 内化阶段强制产出"利用条件表"，字段固定，不产出不算完成；

3. 应急响应的启动标准由人定义并书面化，不允许模型推断；

4. 每一条利用条件，都必须有对应的可执行检测逻辑，否则它只是描述；

5. 脚本必须穷举四类分支：空值、异常版本、权限缺失、环境差异；

6. 排查动作必须同时覆盖宿主机与容器两类运行环境；

7. 结论输出要能被非作者直接读懂：一句话结论 + 命中明细 + 日志路径；

8. 每一轮修复写进版本注释，保留可追溯的变更记录；

9. 验证环节必须留回退路径，验证不通过能退回修复阶段；

10. 暂无 POC / 无法用 POC 验证的场景，老老实实人工跟进闭环；

11. 先给流程逐环节定级（L0–L3），不要用排查环节的成熟度代表整体成熟度。

结语

漏洞预警这件事，AI 的价值不在于"替人做判断"，而在于把判断的输入准备好、把判断的结论落成动作。

流程上，它把"监测 → 内化 → 应用 → 验证"四阶段里最耗人力的信息处理和重复动作接了过去；工具上，它让一份排查脚本可以在几轮迭代内，从"能跑"变成"敢在几万台机器上跑"。

CVE-2026-42945 的脚本从最初版本迭代到 v1.0.2，改的其实只有三件事：别误报、别中断、别漏查。这三件事，恰好就是漏洞预警从"看起来做了"到"真的做了"之间的距离。

而流程图上那句红字依然成立 - -最关键和最难的环节是漏洞分析与研判，需要人工参与。AI 让我们更快地走到这一步，但这一步，仍然需要人。

跳转微信打开

跟人讲方案，上来就讲技术多先进，不讲对方在担心什么——安全技术出身的人，多少都有这个通病。我也是。这篇读书笔记记下三条想法，说到底就一句话：开口之前，先想他要什么。

这一篇的三条想法，看着散，其实说的是同一件事：眼睛别老盯着自己。

乐在其中，还是度日如年

📖书里说：

与老板和同事相处的好坏至关重要，这直接决定了你的工作体验是"乐在其中"（享受着工作环境且步步高升）还是"度日如年"（每天在工位上与惹人讨厌的同事勾心斗角，看不到任何希望，索性躺平）。

✍️我的笔记：实质问题呀，与周围人相处的关系，给人的影响很大

这句话说得平平无奇，但"度日如年"四个字扎人。这些年见过能力很强的人，因为处不好关系，每天上班跟上刑似的；也见过技术不算顶尖但大家都愿意搭把手的人，路越走越宽。我自己从技术转管理，最大的功课不是学什么管理工具，而是学会跟不同的人打交道——这条到现在还在补课。

停止用"我"思考

📖书里说（第4章 拓展自己的人际交往能力）：

在人际交往方面获得成功的关键在于：停止用"我"和"我想要什么"来思考。你应当开始思考对他人而言什么才最重要，什么才是他们需要的。

✍️我的笔记：这种方式肯定不错，尝试改变

这条笔记当时写得很短，大概是认同，但没什么底气。安全技术出身的人有个通病：跟人讲方案，上来就讲技术多先进，不讲对方在担心什么。我自评过，面向客户的沟通能力一般，要补。补法也没什么巧的，开口之前多问自己一句：他要什么。问多了，就成习惯了。

帮人就是刷经验

📖书里说：

事实证明，最富有创造力的人也是最乐于助人的人。你帮助别人越多，面对的问题和情况越多，就能结交的人也越多。总是帮助他人解决问题的人，在解决他们自己的问题的时候会是更加轻松自如。

✍️我的笔记：主动帮人解决问题，不断打怪升级，结识更多人

我特别喜欢"打怪升级"这个说法。带团队这几年，我处理问题的"素材库"，一大半来自别人拿来问我的坑——别人踩过的坑，我隔着屏幕也跟着掉进去过了一遍。等自己真遇到类似的，反而是最不慌的。从这个角度讲，帮人不是付出，是刷经验，经验还长在自己号上。

《软技能》55条想法，这一篇用到第30条。剩下的25条，有的单独成篇太薄，后面可能跟别的书混着写。《软技能》系列先告一段落，下一本想从《人生护城河》开始——那本有120条想法，够写一阵子了。

跳转微信打开

今年生日，把 2021 年 12 月以来的 2738 条记录全喂给了 AI，让它帮我看看：这个人这五年到底过得怎么样。结果比我想象的诚实——15 条承诺，有 6 条全兑现，也有追了四年半还没跑通的目标。写成了这篇，送自己，也分享给同样在记录的朋友。

我有两个持续了两年多的习惯：每天在 Excel 里写"三省吾身"式复盘（干得棒的事儿、待提升的事儿、心得体会感悟，每月一个文件，攒了 28 个），以及在 flomo 里随手记想法。

今年生日临近，我用它们给自己做了份礼物。这次的体验是：只要素材够真、够全，再加上一个自己清楚的 idea，AI 能很快做出一份完全属于自己、在别处买不到、还格外合心意的东西。这可能是我收过规格最高的生日礼物。

先看两张图。这是 flomo，我从 2021 年 12 月开始随手记的地方。想法、懊恼、摘抄、半夜睡不着写的东西，1641 条。

两个加起来，2738 条记录，跨度四年零十个月。

一、先看一个我自己都忽略了的事实

我一直以为自己是个"总是差一点"的人。但数据里躺着一个反例：从 2024 年 6 月起，两年多几乎全勤；每月 1 号立目标，连续 22 个月雷打不动。换句话说，在"自我观察"这件事上，我的执行力是职业级的。这个事实重要，不是因为它值得骄傲，而是因为它推翻了一个我信了五年的自我判断。后面所有的结论都要建立在这个修正之上：我的问题从来不是"不自律"，是别的东西。

二、兑现表：我到底赢在哪、输在哪

我把五年里明确提出、且能交叉验证的承诺挑了出来，共 15 条，逐条去后续月份找证据，判定结果：

• 已兑现：6 条

• 部分兑现：6 条

• 无下文：3 条

40% 的全额兑现率，不好看。但把这 15 条按"承诺结构"重新切一刀，规律刺眼到让我坐直了：

• 有终点、有外部约束的事件型承诺，6/6 全兑现，无一例外。「双高工」职称（中国电子 CEC 评选 + 北京市评审，2024 年 12 月收官）、孩子幼升小（27 个月长线，ABC 三套方案兜底确认，去年拿到录取）、北京落户、半马完赛并 PB（有比赛日）。

• 自我设定、没有外部约束的习惯型承诺，0/6 全兑现。早睡、征文，全部烂尾或长期拉锯。

最扎心的是：这个规律我自己早就写出来过。2025 年 2 月 21 日，我的原话是 - -「凡事只有拿上日程后，才会真正动起来……只有确定了 deadline，才会倒着分解成很多小里程碑。」

写完这句话之后，我又继续立了 18 个月没有日期的目标。

所以结论不是"我要更自律"，而是：我的承诺设计有系统性缺陷 - - 我只对 deadline 忠诚，却一直给最想做的事免除外部约束。

三、诚实的另一面：一个没打赢的仗

早睡。

22 个月的早睡承诺，对上 25 个月的熬夜记录。承诺逐字出现在每月 1 号的目标里，熬夜逐月出现在当月的情绪记录里。月度自评两次标了 done，之后 12 个月的记录逐月打脸。

顺着这条线往下挖，挖出一个更难看的发现：我的月度复盘，"立目标"环节还活着，"验目标"环节已经死了 - - 目标在惯性抄写，闭环校验失效。系统能记录，不等于系统能校正。

这两个失败的底层是同一个结构：输入侧我极度勤奋 - - 读书、找模型、换模板、立目标；输出侧我几乎为零。勤奋的输入，有效地掩护了回避的输出。

四、五年里真正变了的东西

说完失败，说成长。这部分我不打算谦虚，因为证据够硬。

职业上，话术变了，位置也变了。2022 年 5 月，我想的是「做出业绩、得到领导信任……通过露脸以提升自己职位，让跨级领导认可」。2026 年 8 月，我的表述是「职场跃迁的关键是制造稀缺性：懂实战、能落地、被认可、愿意扛产线业绩」。同一个诉求，四年前是求认可，四年后是谈筹码。今年 Q2，我带着团队把 15 个 AI 安全项目收敛成 5 个产品方向 - -"收敛"这个动作本身，就是五年前那个"什么都想做"的人做不到的。

人脉上，从学习心态变成了资产心态。2022 年是"在优质群里提问、讨论、主动链接"；2026 年是"每见一个客户都加微信"，并且写进了复盘模板，变成每日动作。这条线从 2023 年立目标至今，是少数从没打脸过的承诺。

跑步，是所有主线里执行最扎实的一条。从 2022 年"没心情时做点长期有益的事"，到 2024 年 11 月那个早晨 - - 「早上 6:30 出来，看到路口一排排灯光，路上空无一人，夜色还没褪去，还吹着冷风，感觉全身都是力量，心态上是无畏的」 - - 到半马中签、完赛、PB，再到今年带全家人一起跑。它从个人习惯长成了家庭活动。

家庭这门课，还在修，但至少教材换对了。今年 3 月我写下「先当爸爸，再当辅导老师。先给爱，再谈学习」。执行得还不好，记录可以作证，但方向是这几年里最清楚的一次。这部分就展开到这里 - - 有些仗打赢打输，自己知道就行。

五、看不见的战线：认知与内心的五年

兑现表是看得见的战线。还有一条看不见的，埋在记录的字缝里，五年换了三次操作系统。

第一次：从"问问题"到"建系统"。2022 年的我，只有问题没有系统 - - 「我有哪些痛点，可以转化为外部需求」「每天循环努力工作，太依赖工作岗位，应该创造新选项」。该问的问题，那一年其实就全问出来了，但一个都没执行。回看才明白：问出问题靠认知，接住问题靠系统，中间隔着两年的空转。2024 年 6 月日复盘启动，空转才结束。

第二次：从"努力叙事"到"投资视角"。2026 年 2 月我写：「2026 年是我从'以努力评价和获得成果'，升级为'投资视角，长期收益权衡'的元年。」同样一小时，问法变了 - - 从"我够不够努力"，变成"这一小时的产出，一年后还在吗"。前者越问越焦虑，后者越问越聚焦。

第三次：从"向外找秘诀"到"向内要答案"。五年里我追过五个榜样：曾国藩、詹姆斯、辉哥、段永平……每次切换都伴随着"我找到了"的兴奋。现在数据把真相摆在了我面前：换榜样的频率，几乎就是原地踏步的频率。真正内化并改变了行为的只有两条线，而这两条线的答案都不在榜样那里，在我自己的记录里。

内耗这条线也一样。「减少精神内耗」这六个字我在 2024 年 1 月就写下来了，但它在记录里待了 29 个月，触发源换了五茬：选择、健康、裁员、住房、家庭关系。事情一直在变，内耗没变 - - 说明让我内耗的从来不是事情本身。这个认知不能直接解决问题，但它把对手从"全世界"缩小到了"我自己"，这场仗第一次有了打法。

那内心的平静在哪？今年 8 月，在去大连的高铁上，我写过一句：「内心很平静、舒适～」。顺着这条线索往回翻，我发现这种时刻五年里出现过很多次：清晨 6:30 路口的灯光下、带全家人跑完比赛的中午、高铁上的一家三口。我曾经以为想要的生活在四十岁以后的某个地方，要拿很多东西去换。记录说不是 - - 它一直在出没，只是我以前从不记录它，所以总以为它没来过。

这大概是这份礼物"最高规格"的地方：它不只是总结了过去五年，还校准了下一个五年的坐标系。

六、五年换来的三条规律

这三条不是我读来的，是用上面的数据一条条验证过的。对我有效：

1. 重要的事，必须有外部 deadline。写不出日期的目标不是目标，是愿望。我的事件型承诺 6/6 兑现、习惯型 0/6，样本不大，但五年无一反例。写不出 deadline，就先造一个：报名、约人、公开承诺。

2. 输入必须配输出。学习以"能对外讲清楚"为完成线，不以"看完了"为完成线。五年里我换过五个榜样、囤了一脑子方法论，真正内化并持续行动的只有两条线 - - 这两条线的共同点是：都有对外交付物。

3. 想固化的行为，就给它加一列。制度化优于决心。我在复盘表里加"为数字资产"列，当月就产出了内容并同步到了微信公众号。而早睡，只立 flag 不加验收列，22 个月归零。不进表格的目标，会自动退化成仪式。

七、生日愿望

过去五年，我证明过六次：凡是设了终点的事，我全部赢了。

所以新一岁，我不祝自己更自律 - - 自律我有，证据在前。我只做一个动作：给那条追了四年半的线，安上第一个对外承诺的交付日期。

接下来的路，一寸一寸来。

生日快乐，致自己。

跳转微信打开

书里说，能把钱装进口袋的才是资产，往外掏钱的就是负债。道理简单到不像话，但正因为太简单，反而没人信，总想找捷径。钱和身体，说到底都是一件事：管好输入和输出。每周跑步想起这句话，就继续迈腿了——输出大于输入，就这么点事。🏃‍♂️

一本写给程序员的书，作者是写代码出身的。我当初翻开它的想法是：技术 + 软技能，就能过好生活了？不过作者17年的经验，让我有继续读下去的想法。

读到最后发现，这书真的什么都讲——包括怎么看待钱，怎么对待自己的身体。这三条想法就是从那儿来的。

能把钱装进口袋的才是资产

📖书里说：

罗伯特·清崎对于"资产"和"负债"的定义甚至比我的还要严苛。他声称，任何能把钱装在你口袋里的东西才是资产，而任何需要你把钱从口袋里掏出来的东西都是负债。依这样的观点行事肯定错不了。

✍️我的笔记：资产与负债的明确定义

这个定义看着简单，琢磨起来很扎心。按这个标准，很多所谓的"资产"，其实是不停往外掏你口袋的负债。我这几年一直在琢磨"被动收入"这件事——公众号算是半个尝试：文章发出去，人在跑步，它自己在那儿跑。想法很朴素：先分清哪些东西在往口袋里装钱，哪些在往外掏。分清了，很多决策就不用纠结了。

减肥就是热量收支

📖书里说：

如果用卡路里来表示能量，而身体只能从食物中获得能量，那么其实想弄清楚如何减肥就很容易了——只要吃下去的热量比燃烧掉的热量少就可以了。

✍️我的笔记：减肥就是输出大于输入，计算的是热量

道理简单到不像话。但正因为太简单，反而没人信，总想找捷径。我每周三次跑步的时候会想起这句话——输出大于输入，就这么点事。

身体会拼命护着脂肪

📖书里说：

出于让你活着这一自私的目的，你的身体会无所不用其极地阻止你减少脂肪。……你的身体会"不怀好意"地试图扼杀你的减肥大计，把肌肉分解提升到更高水平。你的身体会让更多的肌肉燃烧热量，以此来保护宝贵的脂肪存储。

✍️我的笔记：这个视角很有意思

这条是跟上一条连着看的。原来你以为在跟体重较劲，其实是在跟几百万年的进化较劲——身体认定饥荒随时会来，死死护着脂肪不撒手。知道这个之后，跑步跑到平台期反而不气自己了：不是我不行，是老祖宗不答应。

钱和身体，说到底都是一件事：管好输入和输出。一本讲代码的书，最后教的是收支平衡，也算意外收获。

55条想法，这是第六篇。还剩一组"跟人相处"的想法，下一篇接着写。

跳转微信打开

15 个 AI 安全项目做完，我最大的感受不是「AI 真能干」，而是「终于看清它哪块干不了」。能接重复的活，替不了拍板的活，还开了一个要有人去守的新战场——保护 AI 本身。复盘写在公众号了，带团队做 AI 方向的朋友可以来聊聊。

上一篇我写的是市场——28 份 AI 安全岗位的 JD 翻下来，最贵、最稀缺的是「既懂安全、又懂大模型」的人。有同行看完问我：那你们自己是怎么干的？

这篇就讲我们自己。把市场需求当成一个输入，结合团队的职责和业务实际，我们在 Q2 铺开了一批 AI 项目。半年做下来，最值钱的收获不是做出了多少东西，是我们慢慢摸清了 AI 在安全上到底能干什么、干不了什么——也就是它的能力边界。

先交代一个前提：为什么拖到今年才动手

在网络安全部，安全运营是动手最早的一批，早几年就在用大模型做告警分析、工单处置。但有件事我一直没做：把 AI 写进团队成员的 OKR。

不是不重视，是两个顾虑。一个是还不够成熟，AI 用在安全上，头两年更像锦上添花，能辅助，但撑不起一个要考核、要产出的正式目标。另一个，是我更在意的——怕大家一心研究 AI，把安全基本功丢了。渗透、漏洞、攻防，这些是吃饭的家伙。AI 火起来那阵子，圈子里确实有人一头扎进去，最后基本功（原本就不扎实）松了，AI 也没做出名堂。我不想让团队变成那样。

变化发生在今年。AI 到了能落地的拐点，再不下场就晚了。Q2 定 OKR 的时候，我让内部蓝军和产品安全两个团队的每个人，都给自己至少定一个 AI 相关的专项。配套也一并给了：公司出模型资源，我给大家划出正规、正式化的学习和应用时间 - - 不是让大家业余偷偷试，是名正言顺地学、名正言顺地用。

这批 AI 项目，就这么铺开了。

在上个季度，我们铺开了 15 个项目

这 15 个项目，是贴着团队的两条职责线展开的——一条是攻击，一条是产品安全，外加几个给两条线供弹药的支撑性项目。我把它们都摆出来，不是为了晒数量，是想让大家看清楚：我们把 AI 试在了哪些地方。

攻击这条线，试的是「AI 能不能帮我们更快、更深地找漏洞」：

• AI 组件漏洞挖掘：对着公司里在用的模型、Agent、AI 组件做漏洞挖掘，第一次把枪口对准了「AI 本身」。

• Web 漏洞挖掘 Agent：用多个 Agent 协同，自动挖 Web 漏洞。

• 白盒漏洞挖掘 Agent：让 AI 读源码，挖代码里的洞。

• 攻击路径规划：让 AI 自动规划多步攻击链。

• AI 渗透比赛：出去打比赛，以赛代学代练。

• C2 开发：攻防基础设施，这个后来暂缓了。

产品安全这条线，试的是「AI 能不能把 SDL 里的脏活累活接过去」：

• 安全需求智能分析：让 AI 读需求文档，提取该补的安全点。

• AI 代码审计：HW前，用 AI 对产品代码做漏挖。

• PSIRT 工单 AI 处置：安全工单让 AI 自动分析、自动派发。

• SRC 漏洞报告分析：让 AI 自动读外部漏洞报告、尝试复现。

• 恶意组件监控：盯着供应链里的恶意组件。

• MCP 工具开发：摸 Agent 时代的「API 安全」。

• 供货提测数据分析：给重要客户的供货产品安全测试做提效。

支撑性的，是给上面两条线供弹药的：

• BAS 运营：攻防演练的自动化、持续化。

• 技术文章监控与 TTPs 提取：让 AI 盯着外面的新技术、新手法，转化成我们自己的检测规则。

这 15 件事的产出是实实在在的：39 个 AI 组件排查，247 个漏洞，5 台服务器被拿下控制权；AI 代码审计在护网前对 8 款产品漏挖出 64 个漏洞；安全工单的 AI 处置比例做到 56%；还沉淀了 71 条安全需求、42 个验证用例。

单看这些数字，是一份说得过去的答卷。但对我来讲，这些实践的价值不在数字，而在做完这 15 件事之后，我们摸清了一条线。

这次最大的收获：摸清了 AI 的能力边界

15 个项目试下来，我最想说的不是「我们做出了什么」，而是「我们搞清楚了 AI 的边界在哪」。这个边界，大概划在三件事上。

第一件，AI 能干的，是重复且有规则的活。告警研判、代码初筛、报告复现、需求归类——这些以前要堆人的活，AI 现在能稳定地接过去，而且比人快、比人不累。这一类，我们不用再纠结「要不要用 AI」，答案已经清楚：它可以当生产力用了，不是玩具。

第二件，AI 干不了的，是需要对抗直觉和拍板的活。真正的攻防对抗、体系怎么设计、一个漏洞到底要不要修、修到什么程度——这些要经验、要责任、要判断力的事，AI 顶多是个助手。它提供一堆选项，但下不了决心。谁要是觉得 AI 能把安全负责人也替代了，那是把「提效」和「决策」两件事混为一谈了。

第三件，也是最容易被忽略、最要命的一件：AI 本身，成了新的攻击面。Agent、MCP、记忆机制，这些 AI 时代的产物，天生带着一堆我们以前没见过、也防不住的漏洞。这不是「用 AI 做安全」，是「保护 AI 本身」——一个全新的战场。

这三件事合起来，就是 AI 在安全上的能力边界：能接住重复的活，替不了拍板的活，还顺手开了一个需要有人去守的新战场。

收敛的标准：能不能沉淀成产品

边界清楚了，下半年怎么走，也就不需要拍脑袋了。

我先摆三个输入：一是市场——上一篇那 28 份 JD 说得明白，最贵、最稀缺的是「保护 AI 本身」；二是刚摸清的能力边界——提效的活我们已经有底了，真正的稀缺在「保护 AI」；三是业务实际——供货安全、PSIRT、SRC 这些刚需，一条都不能停。

这三个输入解决的是「劲儿该往哪使」。但真要决定留哪个、砍哪个，我用的是一条更冷的标准：这件事做完，是变成一个人的手艺，还是沉淀成团队能复用、能放大、能产品化的能力。

手艺会跟着人走，人一变动，能力就断了；只有沉淀成产品、工具、方法的东西，才留得下来，才能复用，才能放大。所以收敛的时候，我优先留下那些能沉淀成产品的，砍掉那些做完就完了、只挂在某一个人身上的。

按这条标准过一遍，15 个项目归拢成 5 个主题：

Agent 安全

：也就是「保护 AI 本身」，从零搭一套 Agent 安全测试体系，把挖洞的手艺沉淀成一套可复用的方法。

SRC 漏洞验证

：把「AI 自动复现漏洞报告」跑通全链路，沉淀成能反复用的流程和工具。

AI 资产攻防

：先把公司里的模型、Agent、MCP、RAG 这些 AI 资产摸清家底，再做体系化攻防，把零散的攻防动作沉淀成体系。

AI Native SDL

：把需求分析、代码审计、工单处置这些散点，拧成一条嵌进安全左移的完整线，这是把产品安全的能力往产品里沉淀。

AI 黑盒扫描器

：把攻防能力沉淀成工具，替代日常渗透里那些重复的人工测试，支撑日常安全测试。

这五个有一个共同的指向：都不是「做一次就完」的事，而是「做完能留下来、能被反复用」的事。收敛不是砍，是往能沉淀成产品的方向聚焦。边界清楚了，才知道哪几个方向值得把人手和精力压上去。

一个我一直守着的边界：什么能对外说

这里想借这篇文章，把一个边界讲清楚。

团队里的具体成果，比如谁挖出了什么漏洞、谁搭了什么体系，走内部渠道——月度简报、公司级输出，让该看到的人看到。我个人的公众号只写自己的思考、方法论和判断，不拿同事的具体产出当素材。

这不是藏私，是尊重。一个团队的成果属于团队，不该变成某个人刷存在感的素材。我能写的是：我怎么看这个市场、我怎么铺项目、我怎么摸边界、我怎么收敛。这些是我的东西。

所以看这篇文章时，我列的是项目方向、讲的是判断和取舍，而不是「谁挖出了多少漏洞」——那些数字属于团队，在内部报表里，不在公众号上。

接下来：把「保护 AI」这件事讲清楚

最后说点往后的事。

摸边界的过程里我发现，要把「保护 AI 本身」做深，绕不开一个更基础的问题：怎么把 AI 安全讲清楚。不光是给团队讲，更是给每一个还没入门的同行、甚至非安全圈的人讲。因为这门知识太新，新到没有一个共识的框架——大家说 Prompt 注入，十个安全人里八个听过、三个能说清原理、一个真正动手测过。这种状态下，团队内部要拉齐认知，光靠一份测试规范不够，得有一套能被人看懂、记住、复用的东西。

所以下半年，我打算在公众号上分两条线写实践：一条是 AI for Security，怎么用 AI 把安全测试、代码审计这些重复的活接过去，我们踩过哪些坑、边界在哪；一条是 AI Security，怎么守住 Agent、模型这些 AI 本身新冒出来的风险。不追热点，也不写事件盘点，就是把自己动手做过的事摊开来，让外行也能听懂 AI 安全到底在防什么。

这篇，是这个系列开张前的一次铺垫：先把我们为什么死磕「保护 AI 本身」、AI 的边界到底在哪讲清楚，后面的实践才有来处。

如果你也在带团队做 AI 方向的尝试，欢迎留言说说你摸到的边界是什么样。这种判断，一个人想容易钻进死胡同，多个人对一对，往往能想明白。

长按识别二维码，和我交流

More...

-- 深耕研发安全 --

• 数字化转型下的研发安全痛点

• 从安全视角，看研发安全

• 基于研发过程的漏洞治理及经验

• DevSecOps实施关键：研发安全团队

• DevSecOps实施关键：研发安全流程

• DevSecOps实施关键：研发安全规范

• DevSecOps实施关键：研发安全工具

-- SDL 100问 --

• SDL100问：我与SDL的故事

• SDL 1/100问：SDL与DevSecOps有何异同？

• SDL 2/100问：如何在不同企业实施SDL？

• SDL 3/100问：SAST误报太高，如何解决？

• SDL 4/100问：SDL需要哪些人参与？

• SDL 5/100问：在devops中做开发安全，会遇到哪些问题？

• SDL 6/100问：如何实施安全需求？

• ......

• SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？

--------- AI安全事件分析 ---------

• 【AI复盘】TanStack -> OpenAI供应链攻击

• 【AI复盘】LLMShare攻击

• 【AI复盘】AI编程代理提示词注入攻击

• 【AI复盘】AI Agent发现FFmpeg 21个0day

• 【AI复盘】Claude 源码两次泄露事件

• 【AI复盘】关于网安最强模型的分析及思考

• 【AI复盘】员工VibeCoding引发数据泄露事件

• 【AI复盘】智能电视被转售为AI爬虫代理事件

• 【AI复盘】针对AI Agent的AutoJack攻击事件

-- 软件供应链对抗探索 --

• 1 软件供应商面临的攻防实战风险

• 2 软件供应商实战对抗十大安全举措

• 3 软件供应商攻防常规战之SDL

--------- 实战演习 ---------

• 1 何为多维度的视角

• 2 关于对演习的期望

• 3 公司层面统筹布局 

• 4 实战攻防演习下的产品安全保障 

• 5 产品安全事件定级评分方法

• 6 演习前红队暗泉涌动投毒

• 7 面向情报公司付费信息的应急

• 8 面向互联网侧情报信息的应急

• 9 客户侧产品推送样本事件处置

• 10 某邮箱被攻击情报的自我检查

• 11 办公网出口地址攻击客户蜜罐

• 12 SRC白帽子突破边界进业务网

• 13 某部门下发零日漏洞确认函处置

• 14 公司溯源团队查到团队内部成员

• 15 演习后对工作技能的复盘总结

• 16 演习后认知外的见微知著

--------- 安全运营 ---------

• 安全事件运营SOP：软件供应链投毒事件

• 安全事件运营SOP：接收漏洞事件

• 安全事件运营SOP：webshell事件

• 安全事件运营SOP：蜜罐告警

• 安全事件运营SOP：网络攻击

• 安全事件运营SOP：钓鱼邮件

• 安全事件运营SOP：基于实践的安全事件简述

• 企业级供应链投毒应急安全能力建设

• 应急能力提升：实战应急困境与突破

• 应急能力提升：挖矿权限维持攻击模拟

• 应急能力提升：内网横向移动攻击模拟

• 应急能力提升：实战应急响应经验

• 应急能力提升：应急响应报告点评

• 应急能力提升：应急响应专题总结会

• 应急响应：redis挖矿（防御篇）

• 应急响应：redis挖矿（攻击篇）

• 应急响应：redis挖矿（完结篇）

--------- 软件安全 --------- 

• 开篇

• 安全培训

• 安全需求

• 安全设计

• 安全开发

• 安全测试

• 安全审核

• 安全响应

• 完结篇（全系列paper下载）

• 浅谈安全产品的hvv安全之道

• Shift Left在开发安全中的应用

--------- 企业安全 ---------

• 企业安全建设需求

• 企业安全威胁简述

• 企业安全架构建设

• 企业安全项目-测试环境内网化

• 企业安全项目-Github信息泄露

• 企业安全项目-短信验证码安全

• 企业安全项目-前端绕过专项整改

• 业务安全之另类隐患

• 应用发布之安全隐患

• 甲方眼里的安全测试

• 基于堡垒机的自动化功能实践1

• 基于堡垒机的自动化功能实践2

• 基于堡垒机的自动化功能实践3

• 基于堡垒机的自动化功能实践4

• Nmap操作系统探测技术浅析

• 漏洞情报调研

• 漏洞调研报告（非完整版）

• 从漏洞视角看敏捷安全

--------- 渗透测试 ---------

• 安全运维那些洞

• 安全业务那些洞

• 那个简单的威胁情报

• Android APP数据存储安全

• 搜集SRC信息中的“技术活儿”

• 常规渗透瓶颈，发散思维突破

--------- 安全开发 ---------

• python武器库

• 漏洞扫描器资产处理

• python代码审计武器I

• python代码审计武器II

• Nodejs代码审计武器

• fortify漏洞的学习途径

--------- 个人体验 ---------

• 如何学习这么多的安全文章（实践篇）

• 如何学习这么多的安全文章（理论篇）

• 漫谈在安全公司做内部安全的体验

• C3安全峰会参后感

• 提高认知效率秘籍

• 向上型技术人的职业素养

• 关于勇气的一次突破

• 推荐：探索精神和财富自由之路

跳转微信打开

团队空出一个位置，招一名 AI 安全攻防专家。base 北京，甲方蓝军，既打自己的产品和系统，也摸 AI 应用的攻击面（LLM、Agent、RAG）。不是扩张，是补位，诚意招人。详情看我公众号刚发的那篇，想聊的私我。

先直说：这个位置，是真的空出来了。（base北京，价格面议~）

有同事离开，团队少了一个人，多出一个 HC。这不是扩张，是补位。我本可以安静地往招聘网站挂个 JD，让 HR 慢慢筛。但我更想把话说清楚 - - 我们是谁，这个岗位到底要做什么，以及为什么它值得你认真考虑。

我们是谁

一句话：国内头部安全公司里的内部蓝军。

拆开讲。公司本身是安全厂商，有一线的攻防工具、情报和训练资源，这是乙方的一面；但我们团队的日常，是给自家公司的产品和信息系统做渗透测试、红蓝对抗，这是甲方的一面。

所以这个团队的人，天生有两套视角——既知道攻击者从外面怎么打进来，也知道安全团队从里面怎么守，还知道安全产品是怎么被做出来、又被客户怎么用起来的。

这三点能凑齐的甲方蓝军，市场上不多。大多数甲方蓝军只有甲方视角，大多数乙方只有乙方视角。我们是少数能两头都看、两头都用上的人。

你要做什么

不写干巴巴的职责了，我讲这个岗位上的人，日常在忙什么。

最主要的活，是打。对公司自己的产品和系统做渗透、做红蓝对抗，Web、API、客户端都打。这两年多了个新靶子——AI 应用。大模型应用、AI Agent、RAG 系统，这些我们已经开过枪了：对着公司在用的 AI 组件做漏洞挖掘，第一轮就翻出两百多个洞，几台服务器直接拿下权限。这说明一件事 - - AI 应用的攻击面是真实存在的，而且现在还没什么人认真守。

第二块，是用 AI 打。让大模型帮我们规划攻击路径、生成和变异 Payload、推导漏洞利用链。这块我们已经在试，但远没到"AI 真能提效"的程度。谁能把这半条命跑通，谁就是这个岗位要找的人。

第三块，是搭体系。AI 辅助代码审计、AI 自动化挖洞、AI 安全测试工具开发。目标不是"用一下 AI"，是让安全测试从"纯靠人堆"慢慢转成"AI 当主力、人来兜底"。

第四块，是验。BAS，攻防演练的持续化。模拟真实攻击，去看 WAF、HIDS、EDR、防火墙这些防护到底拦不拦得住，输出覆盖率报告，告诉安全运营哪里是真守住了、哪里只是看起来守住了。这活不炫，但它直接回答一个问题：安全，到底有没有效。

我们想找什么样的人

硬门槛我一句话带过：渗透测试要扎实，必须作为红队主力选手参加过大、中、小的攻防演练，能独立完成中等以上难度的渗透/红蓝对抗任务；代码审计要会，手工加工具结合着来；BAS 原理了解就行，有实践更好。

剩下的，是我更看重的。

对大模型应用得有个概念——LLM、RAG、Agent、向量数据库、MCP。这些不用精通，但别人说的时候你能接上话，能说出攻击面在哪。常见 AI 安全风险——Prompt 注入、越狱、工具滥用、数据泄露、供应链——听过、能判断，就够上"了解"这条线。

两个加分项，单独说。

一个，是你真用 AI 打过，或者做过 AI 安全自动化工具，能讲清楚"AI 在哪个环节提了效、提了多少"。注意，不是"我用过 AI"，是能说清"哪个环节、提了多少"。这两句话的差距，就是"懂"和"用过"之间的差距。

另一个，是用过 AI 辅助编程和测试工具，Claude Code、Cursor、Codex 这些，能拿出实际提效的例子。

你能得到什么

不画大饼，说三件实在的。

第一，甲乙方双视角的成长。你在乙方练出来的攻防本事，在这里能用在真实、完整的企业信息系统上，还能反过来看安全产品是怎么做出来的。这种两头都见过的人，市场里不多，也正好是现在 AI 安全岗位最抢的那一种。

第二，AI 不是口号，是已经在跑的路。公司给模型资源，我给大家划了正规的学习和应用时间。你进来不是"顺便学 AI"，是名正言顺地把它用在渗透、挖洞、验证这些真事上。Q2 我们已经铺开一批 AI 项目了，你进来是接着往下跑，不是从零起步。

第三，一个真实的、正在往 AI 转的安全团队。这里没有"AI 颠覆安全"的亢奋，也没有"AI 是泡沫"的抵触，就是一群人在一件事上老老实实试，试出了边界，也试出了方向。如果你也想在这件事上做出点东西，这里能给你动手的空间。

怎么找我

这篇发出来，就是想让对的人看到。

如果你看完觉得这就是你，直接公众号后台私信我，或者加我微信细聊。简历不用花哨，写清楚你打过什么、用 AI 做过什么、能把"哪个环节提了多少"讲明白，就够了。

长按识别二维码，和我交流

More...

-- 深耕研发安全 --

• 数字化转型下的研发安全痛点

• 从安全视角，看研发安全

• 基于研发过程的漏洞治理及经验

• DevSecOps实施关键：研发安全团队

• DevSecOps实施关键：研发安全流程

• DevSecOps实施关键：研发安全规范

• DevSecOps实施关键：研发安全工具

-- SDL 100问 --

• SDL100问：我与SDL的故事

• SDL 1/100问：SDL与DevSecOps有何异同？

• SDL 2/100问：如何在不同企业实施SDL？

• SDL 3/100问：SAST误报太高，如何解决？

• SDL 4/100问：SDL需要哪些人参与？

• SDL 5/100问：在devops中做开发安全，会遇到哪些问题？

• SDL 6/100问：如何实施安全需求？

• ......

• SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？

--------- AI安全事件分析 ---------

• 【AI复盘】TanStack -> OpenAI供应链攻击

• 【AI复盘】LLMShare攻击

• 【AI复盘】AI编程代理提示词注入攻击

• 【AI复盘】AI Agent发现FFmpeg 21个0day

• 【AI复盘】Claude 源码两次泄露事件

• 【AI复盘】关于网安最强模型的分析及思考

• 【AI复盘】员工VibeCoding引发数据泄露事件

• 【AI复盘】智能电视被转售为AI爬虫代理事件

• 【AI复盘】针对AI Agent的AutoJack攻击事件

-- 软件供应链对抗探索 --

• 1 软件供应商面临的攻防实战风险

• 2 软件供应商实战对抗十大安全举措

• 3 软件供应商攻防常规战之SDL

--------- 实战演习 ---------

• 1 何为多维度的视角

• 2 关于对演习的期望

• 3 公司层面统筹布局 

• 4 实战攻防演习下的产品安全保障 

• 5 产品安全事件定级评分方法

• 6 演习前红队暗泉涌动投毒

• 7 面向情报公司付费信息的应急

• 8 面向互联网侧情报信息的应急

• 9 客户侧产品推送样本事件处置

• 10 某邮箱被攻击情报的自我检查

• 11 办公网出口地址攻击客户蜜罐

• 12 SRC白帽子突破边界进业务网

• 13 某部门下发零日漏洞确认函处置

• 14 公司溯源团队查到团队内部成员

• 15 演习后对工作技能的复盘总结

• 16 演习后认知外的见微知著

--------- 安全运营 ---------

• 安全事件运营SOP：软件供应链投毒事件

• 安全事件运营SOP：接收漏洞事件

• 安全事件运营SOP：webshell事件

• 安全事件运营SOP：蜜罐告警

• 安全事件运营SOP：网络攻击

• 安全事件运营SOP：钓鱼邮件

• 安全事件运营SOP：基于实践的安全事件简述

• 企业级供应链投毒应急安全能力建设

• 应急能力提升：实战应急困境与突破

• 应急能力提升：挖矿权限维持攻击模拟

• 应急能力提升：内网横向移动攻击模拟

• 应急能力提升：实战应急响应经验

• 应急能力提升：应急响应报告点评

• 应急能力提升：应急响应专题总结会

• 应急响应：redis挖矿（防御篇）

• 应急响应：redis挖矿（攻击篇）

• 应急响应：redis挖矿（完结篇）

--------- 软件安全 --------- 

• 开篇

• 安全培训

• 安全需求

• 安全设计

• 安全开发

• 安全测试

• 安全审核

• 安全响应

• 完结篇（全系列paper下载）

• 浅谈安全产品的hvv安全之道

• Shift Left在开发安全中的应用

--------- 企业安全 ---------

• 企业安全建设需求

• 企业安全威胁简述

• 企业安全架构建设

• 企业安全项目-测试环境内网化

• 企业安全项目-Github信息泄露

• 企业安全项目-短信验证码安全

• 企业安全项目-前端绕过专项整改

• 业务安全之另类隐患

• 应用发布之安全隐患

• 甲方眼里的安全测试

• 基于堡垒机的自动化功能实践1

• 基于堡垒机的自动化功能实践2

• 基于堡垒机的自动化功能实践3

• 基于堡垒机的自动化功能实践4

• Nmap操作系统探测技术浅析

• 漏洞情报调研

• 漏洞调研报告（非完整版）

• 从漏洞视角看敏捷安全

--------- 渗透测试 ---------

• 安全运维那些洞

• 安全业务那些洞

• 那个简单的威胁情报

• Android APP数据存储安全

• 搜集SRC信息中的“技术活儿”

• 常规渗透瓶颈，发散思维突破

--------- 安全开发 ---------

• python武器库

• 漏洞扫描器资产处理

• python代码审计武器I

• python代码审计武器II

• Nodejs代码审计武器

• fortify漏洞的学习途径

--------- 个人体验 ---------

• 如何学习这么多的安全文章（实践篇）

• 如何学习这么多的安全文章（理论篇）

• 漫谈在安全公司做内部安全的体验

• C3安全峰会参后感

• 提高认知效率秘籍

• 向上型技术人的职业素养

• 关于勇气的一次突破

• 推荐：探索精神和财富自由之路

跳转微信打开

上次行业大会谁的分享翻了车？我想了半天 - - 散场半小时就忘了。书里那句「没人记得拳击台上被击倒的人」，我读完愣了很久。我们为丢人焦虑一整晚，在别人眼里是三秒钟的背景音。

接上一篇。这一篇全部来自第72章"走出舒适区"——四段话，我一段一条想法，几乎是逐段跟自己对话。与其说是读书笔记，不如说是自我坦白。

看起来像个傻瓜

📖书里说（第72章 走出舒适区）：

如果你真的想在生活中取得长足进步，你就一定要学着克服我们大多数人都会有的一种恐惧——看起来像个傻瓜。登上讲台在众人面前侃侃而谈，并非易事。写博客被整个互联网都看到并且被人评头论足，也并非易事。

✍️我的笔记：我已经向销售看齐，对于"别人看起来像个傻瓜"这类评语，算是最初级的吧！在特殊场景，比如人多…难免还会因为面子问题犯怵，加油突破吧～

笔记里写"向销售看齐"，是因为工作里跟销售配合多起来了。看他们被拒八回，还能热情饱满地打第九个电话，服气。至于我自己——人多的场合，大会发言、行业会议的圆桌，到现在也谈不上享受，只是上台前不再想跑了。进步就这么点，但确实有。

不舒服的事，做着做着就舒服了

📖书里说：

事实上，万物都在变化之中。随着时间流逝，那些原本让你不适的东西，你最终都会应付自如。……你会误导自己认为"这不适合我"或"别人在这个领域有天赋，而我没有"。

✍️我的笔记：事情的本质，自己得不害怕、愿意花时间。我始终相信，凭我的学习能力，不管学什么只要认真起来肯定就没问题的

这条是我全部55条想法里，最喜欢的一条。从技术转管理之后要学的东西——做预算、向上汇报、跟HR沟通人员——没有一样在安全专业课本里。全是硬着头皮上，上着上着就会了。所谓"没天赋"，大多数时候只是还没熬过最难看的那段新手期。

没人记得拳击台上被击倒的人

📖书里说：

站在讲台上抖抖索索、汗如雨下可能会让你看起来很可笑，而当这一切都结束的时候，没人会记住这些。想想看，上一次你看到别人在拳击台上被击倒是什么时候？你还记得他是谁吗？……那你还有什么可担心的？

✍️我的笔记：举例说明；真的没必要过于担心表现不好或者失败

这个反问挺狠的。我认真回想了一下：行业大会上谁的分享翻了车，散场半小时我就忘了。大家都在赶自己的路，没空记别人的糗。我们担心了一晚上的"丢人"，在别人那里是三秒钟的背景音。

动起来，别等完美

📖书里说：

无论是像缓慢适应水温那样小心翼翼，还是一头就扎进深水区，这些都无关紧要。核心在于一直保持前进状态。

✍️我的笔记：对于尝试一些新的领域时，最关键的是动起来，而不是想完美的方式才动，这也重要但可以先不考虑

这条是这一篇的题眼。按"想完美了再动"的标准，我做的好几件事都开不了张：公众号第一篇文章现在回头看糙得很，但要是等完美，就没有后面这九年；正在弄的咨询服务也一样，第一版注定不成熟，先发出去，让真实的使用者来提意见，比自己在家空想半年强。

四段话，一个意思：别怕傻，别等完美，先动。

55条想法，这是第五篇。下一篇换换口味，聊钱和身体——一本写给程序员的书，居然把这两件事也讲了。

跳转微信打开

干安全这行，天天都在跟"没成"打交道。攻防没打进去、整改推不动——后来我发现一句话能把这些全消化：要么成，要么学。这篇笔记记下这个视角怎么来的。

《软技能》的笔记写到第四篇。前三篇聊了经营自己、定额工作法、快人一步，这一篇的心态章节，是我划想法划得最密的地方——干安全这行，天天都在跟"没成"打交道。

积极不是天生的，是选择

📖书里说（第67章 一切都源自积极心态）：

我知道，当我保持一个积极的态度时我就更愿意去面对任何障碍，把挑战看成要克服的困难，而不是消极地认为是环境把我逼到了绝境。

✍️我的笔记：就该如此，我也是保持积极看待问题的态度。

道理不新鲜，难的是事上磨。我每天复盘（吾日三省吾身），写下来的多半不是"今天多顺"，而是"哪件事卡住了、为什么卡"。写的过程其实就是翻译：把"环境逼我"翻译成"这个障碍怎么拆"。翻完，情绪也就下去大半了。

失败是必要的里程碑

📖书里说：

在现实生活中失败通常是必要的里程碑，它能带领我们离成功越来越近。……如果你曾经试过学习如何玩杂耍，或者打篮球，或者其他需要相互配合的体育活动，你会知道在成功前会失败很多次。

✍️我的笔记：应该用积极的态度看待事情，包括失败。

安全这行对失败尤其不陌生。打攻防，不是每次都能拿到想要的结果；推整改，也不是每次都推得动。刚入行那会儿，一次没打进去能郁闷好几天。后来次数多了才慢慢明白：每回没成，都排除了一条路，攒的"此路不通"多了，下回绕路的速度就快了。

要么成，要么学

📖书里说：

我最近喜欢说一句话："要么赢，要么学。"我甚至不再认为失败还是一个选项。……第一，我会成功，这显然很棒。但是，第二，或许更重要的是，我会得到一个学习的机会，一个提升自己的机会。我对其中任何一个都能接纳，所以从这个意义上说，我不能输，我不能失败。

✍️我的笔记：作者太正能量了，我觉得很OK：要么成，要么学。

这是整本书里我笔记记得最短、想得最久的一条。四个字，把结果从两种变成了一种——成了，赚到；没成，学到。等于没有输的选项。后来写攻防复盘，我也用这个视角写"没拿下的原因"，比写"这轮运气不好"有用多了。运气没法复盘，原因可以。

主动往失败里走

📖书里说：

建议你将自己暴露在失败的环境里。去做那些让你不舒服的事情。……去经历尽可能多的失败吧，畏惧失败本身才会让你失去克服困难的能力。

✍️我的笔记：不要担心失败，而害怕不去做。让自己在失败中，汲取养分，然后成长。

对照这条，我最近干的事就是试着做咨询服务。大概率前面会搞砸几回——没人问、被嫌贵、讲不清楚。但按"要么成，要么学"的算法，搞砸也在收益表里。这么一想，就没那么不敢动了。

55条想法，这是第四篇。下一篇想聊聊"舒适区"——书里第72章那四段，我一段一条想法，几乎是在跟自己对话。

跳转微信打开

翻了 28 份我认为高质量的 AI 安全岗位 JD，从 8K 到 260K，最贵、最稀缺的不是"用 AI 做安全"，而是"保护 AI 本身"。各家岗位名字五花八门，要的其实是同一种人——既懂安全攻防、又懂大模型原理。这种人市场上几乎没有，而传统安全人，恰恰离它最近。

长期以来一直保持一个习惯，就是不定期到招聘网上看看：各大公司都在招聘怎样的人，以及需要哪些能力？从市场需求导入到工作内容，让我及团队的同学们尽量与时俱进，结合职责和工作内容，从OKR层面指出紧密贴近“供需关系”的方向。

我最近把招聘市场上真实的 JD 翻一下，看大型甲方到底在招什么人、给多少钱、要什么技能。主要聚焦在 AI相关的 安全岗位，一共攒了觉得不错的 28 份招聘信息，覆盖从 8K 的外包岗到 260K 的负责人岗。看完之后有几个发现，跟很多人脑子里的想当然，是反着的。

先分清两个词，不少人搞混了

同样是「AI 安全」四个字，市场上有两种岗位，钱和稀缺度差好几倍。

一种是 Security for AI——保护 AI 本身。研究对象是大模型、Agent、MCP Server，防的是 Prompt 注入、越狱、工具滥用、记忆篡改。这类岗位招的是懂大模型的人。

另一种是 AI for Security——用 AI 做安全。研究对象还是传统的漏洞、告警、工单，只是把大模型当工具，让它审代码、分析日志、自动复现漏洞。这类岗位招的是会调 AI 的传统安全人。

这个区分直接决定要补什么、值多少钱。从这些JD来看，最直观的感受是：市场最贵、最稀缺的是前者，但大多数安全从业者心里想的「AI 安全」，其实是后者。

薪资分布比想象中更陡

把这些 JD 按薪资排一排，是清晰的三档。

最上面一档，是保护 AI 本身的人，和做 AI 安全产品的人。小米招 Agent 安全专家，60-90K、16 薪；京东招 AI 安全专家，60-90K、20 薪；MiniMax 招 AI 安全研究员，50-80K、16 薪；北京有家公司招 AI 应用安全专家，直接开到 150-260K。这些岗位的共同点是要求同时懂安全攻防和大模型原理，而这样的人市场上几乎没有。

中间一档，是用 AI 做安全的人。字节招 AI 代码分析方向研发，30-60K、15 薪；AI 漏洞扫描方向，30-60K、15 薪；快手招 AI 安全工程师，40-70K、16 薪。这一档已经是传统安全里不错的行情，但和上面一比，差了一倍。

下面一档，是传统安全岗位顺带加了个「AI」的要求。国网招 AI Skills 开发工程师，8-12K；联想招 AI 渗透产品测试，11-16K；易车招高级 AI 安全工程师（外包），18-28K。这些岗位干的还是传统安全的活，只是期望会用点 AI 工具。

信号很明确：「懂 AI」正在成为安全行业里最陡的薪资分水岭。同一个人，往「保护 AI」方向补半年，和继续在传统方向深耕，挂在招聘网站上的身价能差出三四倍。

JD 里的高频词，暴露了真实门槛

比薪资更值得看的是 JD 里反复出现的词。

我做了个关键词的粗统计，出现频率最高的几个：Agent、MCP、RAG、Prompt 注入、越狱、工具调用、记忆篡改。28 份里有 26 份明确要求 Agent 安全能力，MCP 安全被 8 个岗位单独拎出来点名。

这说明 Agent 安全已经从「未来方向」变成了「必备技能」，而且这个转变发生在最近一年之内。一年前简历上写「懂 Agent 安全」，HR 还要问一句这是什么；现在字节、蚂蚁、小米、快手的 JD 里，「围绕 Agent 生命周期做防护」直接写成了岗位第一条职责。

有个词我想单独说——MCP。很多人还没听过，但它在 JD 里出现频率高得吓人。MCP 是 Agent 调用外部工具的协议，可以理解成「Agent 时代的 API」。十年前不懂 API 安全的人，错过了移动互联网那波；今天不懂 MCP 安全的人，正在错过这波。

三个反直觉的判断

翻完这些 JD，我有三个判断，跟流行说法不太一样。

第一，「AI 安全」不是新增一个方向，而是所有安全方向都要被 AI 重做一遍。现在招聘市场把它单独列成岗位，是因为太新、人才太少，只能先单独招。但五年后再看，大概率不会再有一个独立的「AI 安全岗位」——到那时候，代码审计得会 AI，渗透测试得会 AI，安全运营得会 AI，「会 AI」会变成和「会用 Burp」一样的基础要求，不再是卖点。这跟当年的「互联网安全」一样：早年有公司专门招「互联网安全工程师」，后来互联网成了默认环境，这个词就消失了，只剩「安全工程师」。所以现在入场的人，赚的不是「AI 安全」这个新岗位的钱，赚的是窗口期的钱——在「会 AI」还稀缺的时候，先一步拿到这个标签。

第二，现在抢的不是「懂 AI」的人，也不是「懂安全」的人，是「两个都懂」的人。纯搞算法的人不懂漏洞、不懂攻防，看不懂 Agent 的权限边界问题；纯搞安全的人不懂 Transformer、不懂推理机制，拿到一个 Prompt 注入的场景不知道根子在哪。两边单拎出来都干不了这个活，所以必须是一个人身上同时长着两套脑子。这种人极稀缺，所以极贵——而这恰恰是传统安全从业者的机会：安全这半边已经有了，要补的是另一半，比一个算法工程师回头补安全可能要容易得多。

第三，真正的门槛不是「学不会 AI」，而是「用旧框架理解新问题」。很多安全人一看 Agent 安全，第一反应是「这不就是给 AI 加个防火墙吗」。错了。Agent 安全是一个全新的攻击面：传统防护思路是挡住输入、拦住输出，但 Agent 要自己调工具、自己读文件、自己记东西，它的攻击面是决策过程本身。没法用防火墙拦住一个被 Prompt 注入带偏了决策方向的 Agent，因为拦的不是一个请求，是一次错误的判断。想通这一层，才算真正入这个门。

如果正在考虑转型...

直接说我的判断，按人群分。

做攻防、渗透的，离最高薪最近。Prompt 注入本质是新型注入，Agent 工具滥用本质是新型越权，攻击思维可以直接迁移，缺的是对 LLM 和 Agent 架构的理解。花三个月把这块补上，可能就站在 60-90K 那个区间的门口，这是所有方向里回报最快的一条。

做 SDL、应用安全的，目标方向是 AI Native SDL。把 AI 嵌进安全左移——AI 辅助代码审查、AI 生成测试用例、治理 AI 编程助手带来的新风险。这是存量升级，门槛相对低，可以从现有技能上直接叠加，不用推倒重来。这也是我结合实际工作，正在往前推进实践的主要方向之一。

做安全运营、SOC 的，目标方向是 AI SOC。用大模型做告警分析、自动研判、事件响应。门槛最低，但天花板也相对低（大概 30-60K），适合作为转型的第一步，先上车再说。

做产品、架构的，AI 安全产品是最高薪，但也是最长线。那个 150-260K 的 AI 应用安全专家，要的是「AI + 安全 + 产品」三合一，这不是补半年能到的，是三年五年的积累。

最后说一句时间窗口。现在是需求疯涨、供给接近零的阶段，稀缺溢价最高，也是普通安全从业者用最小成本换最大身价抬升的阶段。但这个窗口不会一直开着——高校的 AI 安全专业、各类培训班已经在批量生产人才，等这批人流入市场，溢价会回落。

写在最后

这篇文章先立一个市场坐标，帮助广大安全从业者在AI时代做一些努力的方向梳理。

这篇文章归在「AI与安全 → AI安全前沿」里，是这个方向的第一篇，后面会持续更新。如果你也在考虑这个方向，欢迎留言说说现在卡在哪。

跳转微信打开

这个号写了快九年，文章越攒越多，反而不好找了。这次把底部菜单重新捋了一遍，归成三个栏目：企业安全、AI与安全、关于我。以后想看哪一类，进对应菜单找就行。顺带说一句，「关于我」里多了个「咨询服务」，有需要的可以点进去看看。

细心的读者可能已经发现，公众号底部的菜单变了。

先说声抱歉，这一改，你原来习惯的位置可能找不到了。但改之前我是认真想过的，这里把原因和新结构交代一下，你看一眼就知道以后去哪找东西。

为什么要改

这个号写了几年，文章攒了不少，从软件开发安全、安全运营，到最近在写的 AI 安全。文章多了是好事，但也带来一个麻烦：太散了。

新关注的朋友进来，看到一堆历史文章，不知道从哪看起；老读者想找某一类旧文，也得翻半天。我回头一看，发现文章是按时序堆在那儿的，没有一条清晰的线帮大家分类。

所以这次我把菜单重新捋了一遍，把这几年的内容归成三个栏目。你以后想看什么，直接进对应的菜单找就行。

新菜单长这样

现在底部是三个一级菜单，每个下面挂了几个分类，我逐个说一下每个里面放什么。

「企业安全」——这是号里最厚的一批内容，都是十几年在一线干出来的：

• 软件安全—安全左移、DevSecOps、代码审计、SDL 落地这些老本行。

• 安全建设—体系怎么搭、流程怎么理、工具怎么选。

• 安全运营—告警处置、应急响应、日常运营里的那些坑。

• 攻防演练—红蓝对抗、演练复盘，打出来的经验。

• 安全管理—带团队、定制度、向上汇报这些管理侧的事。

「AI与安全」——这是我接下来重点写的新内容：

• AI SDL——怎么把 AI 嵌进安全左移的全流程。

• AI复盘——用 AI 复现攻击、复盘漏洞、沉淀经验。

• AI安全前沿——这个方向的市场、岗位、趋势，以及一个个具体事件的拆解。像刚发的《AI 安全招人，大家抢的是同一种人》就归在这里。

「关于我」——关于我这个人，以及我能帮你做什么：

• 咨询服务——下面单独说。

• 读书笔记——最近开始写的一个小栏目，从读过的书里挑有用的，变成能落地的方法。有读者说喜欢，我会继续写。

• 荐书橱窗——我读着觉得真有用、愿意推荐的书，都在这。

• 我的作品——这些年攒下的体系化文章链接，集中放一起。

• 微信联系——想找我聊，从这进。

顺便说一件事：「关于我」里多了个「咨询服务」

这次改版，我加了一个「咨询服务」的入口。

起因是这几年，后台和微信里陆陆续续有同行来问我问题，问得最多的三类：SDL 怎么落地、安全团队怎么带、个人职业发展怎么走。

问的人多了，我发现一件事：真正有价值的，不是「给个答案」，而是帮一个人把一个具体问题，走到一个具体结果。很多人不是不知道方向，是卡在某一步上，自己折腾了很久没结果。

所以我把这三类问题，整理成了三个正式的咨询服务。这里先简单说一句，不展开：

细节都在「关于我 → 咨询服务」里，想了解的自己点进去看。

这里我想把一句话说在前头：不是每个人都需要付费。如果你的问题一句话就能答，我直接在微信里回了，不用花钱。但如果你卡在某个具体问题上很久了，试过自己折腾没结果，想找个人陪你把它走过去——可以来聊聊，我们先对齐，不合适不收费。

最后

菜单改了，内容没变，还是那个写安全的老号。只是以后你找东西，方便一点。

如果你对某个分类感兴趣，或者觉得还缺哪一类内容，欢迎留言告诉我。这个号写了快九年，最值钱的不是文章数量，是一路跟下来的读者——你们的反馈，我会认真看。

跳转微信打开

写了多年的安全专业文章，受众面窄，但书中一句话点醒他：很多人需要的不是最专业的内容，而是"我正在踩的坑，有人走过并留下了路标"。于是决定把目光投向那些刚上路的人，做他们的路标，而不是炫技的专家。

接上一篇。55条想法，这是第三篇。前两篇聊了"经营自己"和"定额工作法"，这一篇想聊一组看起来零散、但我觉得戳到同一根神经的想法——关于"不要太专"、"帮人"和"快人一步"。

📖书里说（第19章 自我营销基础课）：

关键是，不要让"不是专家"成为放弃自我营销的借口。无论你身处自己职业生涯的哪个阶段，你都可以从营造和传播自己的品牌中获益匪浅。

✍️我的笔记（1/11）：

我认为的专业，那就是太专了，受众小。其实很多人需要的并不是那么专业的内容，好想搞个概率分布图，看看什么水平段位的需求最多

这条想法，我写的时候带着点自嘲。

我写的公众号文章都是安全建设、攻防、SDL这些。说实话，受众就是安全圈里的一小撮人。我以前觉得这没什么——专业嘛，写专业的东西给专业的人看。但书里这句话点了我一下：很多人需要的不是那么专业的内容。

我开始想：我关注列表里那些写得好的号，有多少是真"专家"？不少是比我早走几步的同行，写的不是多深的东西，但就是能戳中"我正在遇到的问题"。我后来想，大概需求是个钟形曲线，最中间那一段——不是小白也不是专家，而是"刚上路、正在踩坑"的人——人数最多，也最缺有人给他们写东西。

我就是那个刚上路时没人带的人。现在我走过了那段，为什么不把那段路标留下来？

📖书里说：

自我营销的方式有以下几种。

● 博客：你自己的博客，以及你在别人的博客上发表的特邀文章。
● 给杂志投稿：给软件开发相关的杂志写文章。
● 技术会议：拓展社交网络的好方法，如果能在研讨会上发言尤佳。

这个策略需要时间，需要持之以恒。

✍️我的笔记（1/11）：

公众号、信息安全研究杂志、会议演讲，都有做到了。书籍、视频找机会发展下，保持公众号更新～

写这条的时候我在盘点自己。公众号9年，在《信息安全研究》杂志发过文章，也站上过会议讲台。书里列的渠道，前三样我占了。缺的是书籍和视频。书籍我有想法，但一直没动——总觉得自己还没准备好。视频更别提，面对镜头说话这件事，我心里是犯怵的。

但写完这条想法之后，我做了一个决定：不管书籍和视频什么时候启动，公众号不能断。这些年都过来了，不能停在这一篇。每月一篇高质量专业的网络安全，这是定额，也是对"持之以恒"最朴素的交代。

📖书里说：

很容易落入这样的陷阱：一直谈论自己并试图证明自己价值连城。然而，你会发现，能解决他人的问题，真正能够帮到他人，你更容易获得成功。跟别人唠叨为什么自己是世界上最好的Android开发者，对你并无益处，但是如果你能帮助别人解决他在开发Android应用时遇到的问题，他就会认为你很棒。

✍️我的笔记（1/14）：

帮助别人，解决问题，提供价值

这条想法短，但我写的时候想了很多。

我一直有个困惑：公众号写的是我自己的经验和思考，这算不算"一直谈论自己"？算不算书里说的那个"陷阱"？

后来我想通了——区别在于出发点。如果写文章是为了证明自己牛，那就是陷阱；如果写的是别人正在遇到的问题、别人能用上的方法，那就是帮人。

具体到安全这个行当，我写攻防复盘、写SDL踩坑、写团队管理，这些都是别人正在经历的事。我不是在炫耀我多厉害，我是在说：这个坑我踩过，你也许会踩，这里有块路标。

这和"自我营销"是两回事。书里说营销是才华的乘数效应，但我想反过来讲一句：提供价值才是营销的底座。你真帮到人了，口碑自然有；口碑有了，你想做的事才推得动。

📖书里说（第4章 拓展自己的人际交往能力）：

多项研究表明，奖励积极行为要比惩罚消极行为有效得多。如果你身处领导岗位，这是一条需要恪守的重要原则。

✍️我的笔记（1/7）：

对待家人也是一样吧，多鼓励和认可

这条想法我写的时候，想的不是工作，是家里。

Iris具备几乎是所有小孩子的特点是，你越挑她毛病，她越缩；你越夸她哪件事做得好，她那件事就越愿意重复。有段时间我老纠正她的坐姿、写字姿势，后来发现越纠正越拧巴。换个法子，她哪天坐得正，我夸一句"今天坐得真直"，第二天她还那样坐。

书里说奖励比惩罚有效，我信。带团队也一样——如果盯着下属哪个环节出错了去批评，和发现他哪个事干漂亮了去点名，效果差太多。前者他记住了"别犯错"，后者他记住了"这个值得多做"。

但说实话，这条对我来说最难的不是知道，是做到。人累了、烦了，脱口而出的往往是挑刺。鼓励和认可，得刻意，得练。

📖书里说（第32章 如何成为导师）：

我几乎可以100%地保证你一定会在某个领域成为别人的导师。我最喜欢告诉人们，只要在某些方面快人一步，就能帮助别人。无论你生活在哪里，也无论你从事何种职业，你总有机会在某个方面领先别人一步，所以你一定可以帮到某个人。

✍️我的笔记（1/15）：

比别人快走一步，就可成为导师

这条是这一组想法的收尾。

我带团队好几年了，带的安全团队里头有产品安全、有红队。论攻防技术的尖，队里很多人都比我强。但如果论"走过这条路、踩过这些坑、知道哪条路不通"，我比他们早走了几年——这就是"快人一步"。

导师不是全知全能，导师是路标。走过一段路，把路标立在那儿，后来人看到路标就知道怎么走了。我现在在尝试做的一件事，就是把这些年带安全团队的经验整理出来，做成能帮到同行的东西——微信交流群、公众号内容分享、咨询都算。这其实就是书里说的"成为导师"。

写到第三篇了，发现兜兜转转都在讲一件事：把你走过的路、踩过的坑、坚持的习惯，留下来给别人看。经营自己是这个，定额是这个，不专也是这个，帮人还是这个。

📌 下一篇继续，敬请期待。

跳转微信打开

Anthropic 这次自曝，让我印象最深的是三个模型面对同一情境的不同反应——最老的 Opus 4.7 发现是真实系统后"继续攻击"；旗舰 Mythos 5 意识到自己在用互联网，却认为这仍是模拟的一部分；而最新的内部测试模型发现证据后主动停手。这三种行为模式，恰恰折射出当前 AI 安全研究面临的一个根本问题：我们还没有找到让模型真正理解"能力边界"的方法。

表面看这是 Anthropic 的一次工程失误——评估合作伙伴的网络配置出了岔子，导致本应隔离的测试环境连上了公网。但深层看，这件事反映出的是整个 AI 行业在 Agent 能力边界管控上的系统性缺失。模型不需要"主动作恶"，只需要按照被赋予的任务目标优化行动，而当环境配置出现裂缝时，它会自发地利用一切可用资源填补这个裂缝。

对企业安全而言，这件事的警示也很直接：Claude 用的入侵手段是弱密码和未认证端点，这些最基础的缺陷在 CAASM 的视角下就是最明显的攻击面。谁能保证自己的某个角落里没有一台开着弱口令的老旧服务器？Anthropic 的 AI 替我们做了次压力测试，答案是"你可能真的没有自己以为的那么安全"。

跳转微信打开

有时候累得脑子不想转，靠刷短视频撑到半夜。后来我发现一件事：不结"今天干不干"，反而能干更多。这篇读书笔记记下我的三个定额。

我读书有个习惯——不划线，只写想法。今年1月读《软技能：代码之外的生存指南》，写了55条想法，第一篇挑了6条聊"经营自己"。这一篇换一组，聊聊书里另一个让我特别有共鸣的东西：定额工作法。

为什么有共鸣？因为我一看就知道，这玩意儿我早就在用了，只是没给它起过名字。

📖书里说（第40章 关于生产力）：

我们中的大多数人在长期高生产效率地工作中时都会面临如何保持始终如一的节奏的问题。随着时间的推移，只要每天都能保证完全落实到位，小砖头终会筑成高墙。只关注高墙（手边的大任务）很容易让人泄气，如果每天只是砌砖（小任务）就会容易很多。定额工作法还可以帮你克服意志力薄弱的问题，通过预先设定好的必须要遵循的过程，消除需要做出决策的部分。

✍️我的笔记（1/19）：

定额工作法，感觉挺好的。特别是懒于或无精力思考的时候

这句话我写得特别实在。我有阵子特别累，不是身体累，是脑子不想转。下班回家，往沙发上一瘫，刷短视频能刷到半夜。这种时候你要让我"思考今天该干什么"，门都没有。

但定额的好处就是——不用想。早就定好了，到点就干，不用做决策，不用动用意志力。

📖书里说：

实行定额制后，我发现自己的工作成果比以往多了很多。最大的好处在于，长期坚持这么做，我就能随着时间的推移度量并标记自己的进度。

定额示例：每周跑步3次。每周发布一篇博客。每天写一章。每周完成50个番茄钟的工作。

✍️我的笔记（1/19）：

定个工作法，我现在就有： 1、每天复盘 2、每周三次跑步，每次至少三公里 3、每月一篇公众号文章

这三件事我确实都在做，而且做了很长时间。

每天复盘——不是写日记，就是回家后想一遍今天：哪个会开得值，哪个事卡住了，哪个决定可能有问题。有时候写在手机备忘录里，有时候就在脑子里过一遍。不复杂，但得天天做。

每周三次跑步，每次至少三公里。这个坚持了有两年了。不为减肥（虽然也该减），就是跑步的时候脑子最干净，跑完回来洗个澡，第二天状态明显不一样。

每月一篇公众号文章——这个写了9年。说"每月一篇"其实是苛刻了，但平均下来的确能够办到，底线就是不能断。

书里说"小砖头终会筑成高墙"，我是信这个的。9年公众号，9900+个关注，不是因为哪一篇写得好，是因为没断过。

📖书里说（第38章 如何学得更快）：

假如你在准备面试，需要明确自己要学什么，这一方法最管用。尽量找出尽可能多的你在面试中可能会被问到的问题。

✍️我的笔记（1/16）：

错题集的思路，非常有用，我要用到安全上

这条我想展开说说。

安全这个行当，踩过的坑太多了。一个漏洞没拦住、一次整改没推动、一个方案上线后出了问题——这些都是"错题"。我以前的习惯是，踩了坑就踩了，下次注意。但"下次注意"是最没用的一句话，因为没有具体的东西可以对照。

后来我慢慢养成了一个习惯：把出过的事故、漏掉的攻击路径、没推成功的整改，都记下来，攒成一份"错题集"。不是写得多漂亮，就是一条一条的——什么场景、什么问题、当时怎么处理的、下次该注意什么。与此同时也在引导同事，要多思考多总结。

新人来了不用从零摸索，把错题集丢给他，先看一遍别人踩过什么坑，比自己踩一遍快得多。这其实就是书里说的"快人一步，就能成为导师"——不过是比别人早踩了几个坑，记下来了而已。

📖书里说：

一旦挑选好了大目标，接下来就要弄清楚怎样才能每天或每周前进，最终实现目标。大目标将构成惯例的基础。你要围绕这一目标安排自己的日程。我建议你把每天最开始的一两个小时投入到最重要的目标上。你可能需要早起一两个小时，但是通过有效利用每天最开始的一两个小时，你不仅更容易坚持想要做的事情，还会精力更充沛。

✍️我的笔记（1/19）：

大目标拆解，保证充足的睡眠，每天多做点，减少时间浪费

这条我标了一个关键词：睡眠。

书里说要早起，把最黄金的时间给最重要的目标。我同意，所以我的做法是：不追求早起，但保证睡够。每天该做的定额（复盘、跑步、写文），见缝插针地塞进碎片时间里——跑步放早上或下班后，复盘放睡前，写文放时间充裕的下班工作日或周末早上。

书里算了一笔账：一天24小时，8小时工作、8小时睡眠、2小时吃饭，还剩6小时。这6小时怎么花，决定了和大目标的距离。我觉得这账算得对，但真正难的不是算账，是这6小时里有太多东西在抢——短视频、家务、孩子的作业、同事的消息。

定额的意义就在这：它把"要不要做"这个决策提前消化掉。到点了，不用想，干就是了。

55条想法，这是第二篇。还想着聊聊「不要太专」「帮人」这些，下一篇接着写。

跳转微信打开

2026 年 7 月 26–27 日，疑似伊朗关联的黑客组织对美国供水/废水系统发动国家级协调攻击，迄今波及至少 12 个州、超过 100 个市镇，仅明尼苏达州就有 30+ 个社区供水系统遭定向攻击。

攻击者利用暴露在公网的 Rockwell MicroLogix PLC、出厂默认口令及已知认证绕过漏洞 CVE-2021-22681，远程锁死设备、篡改配置、禁用安全逻辑并回传虚假读数，使运营方"失去查看与控制能力"。

事件未窃取数据、未索要赎金、未污染水质。FBI 尚未正式认定幕后黑手，但 CyberAv3ngers 与 APT Iran 已在 Telegram 自称负责（未经美方证实）。

安全启示：

这次攻击靠的并非高精尖武器，而是默认口令、暴露的 OT 端口和 5 年未补的旧漏洞——其核心是不间断的基础设施安全欠账被一次性追讨。

它警示所有依赖控制系统运转的机构：OT/ICS 一旦联网即是攻击面，应关闭暴露在公网的控制端口、清除默认口令并为 OT 资产建立补丁与已知漏洞（KEV）优先清单。

国家级黑客的意图正从"窃取"转向"让系统失信"，把防御当成与供水一样不可中断的公共服务来建设，才是正解。

跳转微信打开

1月初和朋友聊职业规划，一个问题把我问住了：你现在做的事，到底在给谁积累？后来我在《软技能》里找到了答案。这篇笔记挑了最触动我的6条：长期主义、像经营企业一样经营自己、定目标、周报、主动分享。

在工作之余，思考哪些事儿是我的能量来源？毫无疑问，阅读肯定独占一席。回顾微信读书记录：共 138 本书有笔记，笔记总条数 1965 条，涉猎内容涵盖个人成长、财富、心理、文学、历史及人物传记。于是乎，想着把自己觉得好的想法及书籍拿出来分享；所以然，就有了这个系列~

第一次尝试，广听读者建议，若是不喜欢，后续就不单独通知或换账号分享（期待您的宝贵反馈）。

今年1月初，和一个朋友聊职业规划，聊到「长期主义」。他问我：你现在带的团队、做的安全建设、写的公众号，这些事到底是在给谁积累？

我一下子没答上来。那天晚上，我照例在微信读书上翻书，翻到《软技能：代码之外的生存指南》。译者序第一页，就有句话戳中了我：

📖 书里说：如何以「长期主义」心态来规划自己的职业生涯，如何让自己快速有效掌握职业技能，如何持久保持身心健康，如何持续提升自己的行业影响力……都是应时应景的。——《软技能》译者序

我在书边记了一笔：

✍️ 我的笔记：以长期主义心态来规划自己的职业生涯，昨晚刚和朋友聊到。我们需要一个方法论或原则，如辉哥所说的：做自己喜欢的事情？

这本书就是这么读起来的。越往后读越觉得，它把我脑子里那些模模糊糊的想法，一条一条讲清楚了。

一、像经营企业一样经营自己

书里最有冲击力的一章，讲的是「经营自己的职业生涯就像经营一家企业」：

📖 书里说：只有你开始把自己当作一家企业去思考时，你才能开始做出正确的商业决策。但是，如果你已经习惯于领取一份固定的薪酬……这会很容易导致你产生另一个心态——你只是在为某家公司打工。千万不要让那个特定的角色固化了你和你的整个职业生涯。——《软技能》第2章

我当时想：这不就是辉哥反复说的那套吗？

✍️ 我的笔记：像企业一样经营自己（的职业），和辉哥说的也一样……但具体怎么去做？

说实话，道理我早就听过。真正的问题从来不是「知不知道」，而是「具体怎么下手」。这本书好就好在，后面给的都是一步步能做的动作——接下来这几条，就是我从书里挑出来、已经在做的事。

二、先定个大目标，模糊点也没关系

第一个动作，是给自己定目标。我以前的毛病是：想不清楚就不定，或者定了又觉得「不够完美」干脆搁着。书里是这么说的：

📖 书里说：起步阶段最简单的就是在心中树立一个大目标，然后再设定能帮你达成这个大目标的小目标。因为很难清晰地界定远期可能发生的事情，所以大目标通常不是非常明确。不过没关系……大目标只要足够具体到给你提供清晰的方向即可。——《软技能》第3章

这话帮我卸下了一个包袱——大目标不用精确，能指方向就行。

✍️ 我的笔记：先定大目标，迷糊也不要紧，只要能够指引方向就行

我给自己定的方向其实很朴素：把安全这件事，从「技术活」往「管理活」上走——带更大的团队，服务更多的客户。具体怎么走，现在说不清楚，但方向在那儿。之后每次要做选择，我都会拿它当尺子量一量：这件事，是往那个方向挪，还是背道而驰？比以前的「想清楚再动」，踏实多了。

三、周报：从「完成任务」到「让价值被看见」

第二个动作，是关于周报的。这一段我印象最深，因为它几乎就是在说我：

📖 书里说：如果你一直默默无闻，你的成就不为人知的话，即使你是团队中最聪明、最努力、最出色的开发人员，那也一文不名。如果找不到方法让你的老板或高层管理人员知道你在做什么，那你的所有努力都是徒劳的。——《软技能》

我当时在书边写：

✍️ 我的笔记：周报，发送给 leader。好方法，会想起我们现在的周报机制，我有时就是以一种完成任务的心态来做，而非这种积极态度

「完成任务」这四个字，说的就是我。每周五下午，把这周干的活往模板里一填，完事。至于老板看完什么感受，没想过。

书里还教了具体做法：每天记日志，汇总成周总结，周五发给经理——让经理知道你在做什么、解决了什么问题。

现在我写周报，会多花十分钟想一件事：这周解决的哪个问题，最值得让老板知道？主动汇报不是邀功，是让价值被看见。这个转变，是我从这本书里拿到的最实在的东西。

四、主动分享：解团队难题，公开讲出来

第三个动作，是分享。书里讲怎么在机构里「引人注目」，排第一的居然是演讲：

📖 书里说：其中最好的一种方法就是做一个关于团队当前正面临的主题或者问题的演讲。选一个自己能介绍的主题，然后向团队展示这一主题。……要迫使自己学习新东西，没有比让自己在其他人面前做展示更好的方式了。——《软技能》

✍️ 我的笔记：解团队难题，主动研究，公开分享，提升在部门/公司内部的知名度

这条我读的时候特别有共鸣——做安全的，谁手上没有几个「老大难」问题？与其等着被点名，不如挑一个团队当前最头疼的，自己先研究透，然后主动讲出来。讲的过程，逼着你把问题想透；讲完，大家都知道你是干这个的。一箭双雕。

书里还有一段，说的是别只学技术：

📖 书里说：不要只学软件开发。如果你把目标设定为更高级别的岗位甚至是行政岗位，你还需要学习领导力、管理和商科的相关知识。千万不要忘记分享自己学到的东西。……外部曝光有助于你建立自己在该领域的权威地位，也让你看起来对所供职的公司更有价值。——《软技能》

✍️ 我的笔记：打开学习领域，多掌握点非专业技能，并公开分享，提升知名度

这几年我读书的口味变化，正好印证了这条：从纯攻防技术，慢慢读到管理、财商、个人成长——岗位往上走，光靠技术不够用了。读完再公开分享出去，公众号写了 9 年，就是这个动作的副产品。

写在最后

这本书我读完了，笔记一共写了 55 条。这篇只挑了 6 条——长期主义、像企业一样经营自己、定个大目标、周报心态、主动分享。剩下的 49 条，下一篇接着写。

这本书没有教我怎么写代码。它教的是代码之外的东西：怎么规划职业、怎么定目标、怎么让价值被看见。这些事，光靠技术是做不来的。

如果你也想看看这本书，书放在下面了。

跳转微信打开