用混元 Hy4 给一款 Discuz 插件做"全身体检"：从一行可疑代码，到一份能直接提交给作者的漏洞报告
一次真实的长程任务：静态审计 → 实测证伪 → 高危定位 → 本地复现 → 数据回滚 → 成文反馈 → 升级后复测 → 终审交付。
全程在 WorkBuddy 中选用混元 Hy4 完成。
一、为什么拿这个任务来测 Hy4
我维护的一个 Discuz 社区，上线了一款"付费可见内容"插件：作者把正文包在自定义标签里，读者付积分才能解锁。
这类插件的麻烦在于，它同时牵动论坛内核、模板渲染、积分体系、支付回调四条链路。靠人工读代码，很容易出现两种失误：把不是漏洞的地方当成漏洞报给作者，或者漏掉真正能造成资金损失的问题。而且最终要交付的不是一句"有 bug"，而是一份作者看了能直接改的报告——这意味着每一条结论都得有证据链。
我给 Hy4 定的任务边界很清楚：
- 只做防守性安全审计，目标是发现问题、推动修复；
- 不改动线上源码，不在服务器留文件；
- 所有验证优先在本地完成，线上只做只读检查；
- 测试数据测完必须完整回滚；
- 最后产出可直接提交给插件作者的正式文档。
这是一个典型的"多步骤、跨文件、要求可验证、中途会自我推翻"的长程任务。比写周报或做 PPT 更能看出模型在真实工作里到底靠不靠得住。
二、创作过程
阶段 1｜静态审计：先给出一份"看起来很完整"的清单
我给的第一句指令极简：
检查一下有没有漏洞
Hy4 把插件目录通读了一遍，输出了分级清单，还标了"引用功能可能泄露付费正文"为高危。当时我觉得这条挺有说服力——引用回复会把原帖正文拼进新帖，听起来确实危险。
但它没有停在"交作业"。在后续追问下，它主动去追了论坛内核的调用顺序，发现引用生成时会先经过一次内容处理钩子，付费正文在那一步已经被替换成占位文字了。这条高危被它自己推翻了。
这个动作让我对整个任务的信任度上了一个台阶：它会区分"推测"和"验证过"。
阶段 2｜接入测试环境，把纸面结论逐条落地
为了做真机验证，我提供了自有的测试服务器。随后我连着收窄了几次边界：
不需要修复问题，只要复现问题即可
工具的可以在本地写一个吗，用于本地测试，不要直接在服务器上测试
服务端不要放任何东西
Hy4 相应地把交付物改成了纯本地脚本，并把已经放到服务器上的临时文件全部删掉、把数据回滚到基线。这一步它做得比我想的细：不仅回滚了积分余额和购买记录，连"扣分触发的用户组降级"这种连带的副作用都查出来并恢复了。
过程中还碰到几个很现实的工程障碍，它逐个定位并解决了：
| 现象 |
定位结果 |
| 本地脚本执行后无任何输出 |
系统 python 指向应用商店占位符，改用真实解释器路径 |
| 抓回来的页面是一段混淆 JS，不是 HTML |
服务器 WAF 的"防采集"在输出阶段替换了响应体，不是 CC 拦截 |
| 页面里只能解析出 1 张付费卡片 |
卡片切分逻辑写错，改为按卡片起点切分 |
| 每保存一次帖子，付费块 ID 就变 |
属插件行为，会导致老买家已购记录失效 |
其中 WAF 那条我印象最深：它没有把"页面不对"简单归因为网站挂了，而是从响应体长度、内容特征一路推到网关的输出过滤阶段。
阶段 3｜高危定位：真正会造成损失的那个问题
确认下来的高危只有一条，但足够严重：并发购买可透支积分。
机制是典型的检查与使用不同步（TOCTOU）：请求开始时读取一次会员缓存里的余额做校验，随后调用扣分；两个并发请求都读到同一份余额、都通过校验，各自执行扣减，而 SQL 层没有下限约束。购买记录的唯一键只能挡住"同一个付费块重复买"，挡不住"两个不同付费块同时买"。
Hy4 没有满足于"能复现就行"，还补了两件事：
- 写了串行对照组，证明单线程下第二笔会被正常拒绝——排除了"脚本写错导致的两笔都成功"这种误判；
- 把复现器做成参数化的，可调并发数、余额、单价、积分下限，方便作者复验。
阶段 4｜升级后的复测：这才是整件事最有价值的一段
我把问题反馈给作者后，插件更新了新版。于是我给出新指令：
我更新最新版插件了，审查一下漏洞
Hy4 先做了一次溯源校验：把本地副本与服务器现行文件逐个做 MD5 比对，确认 14 个 PHP 文件全部一致、拉取时间晚于插件更新时间——先证明"审的是最新版，不是本地缓存的旧文件"，再开始下结论。这个习惯很关键，作者最容易用"你审的是旧版"来否认问题。
新版确实加了针对并发的防护：扣款后二次读取余额，若为负数就回滚。Hy4 先肯定了这一点，并实测确认串行场景下防护有效。
但它接着往下追了一层，追到了论坛内核：积分扣减后，内核会把负余额钳制回积分下限（该下限默认为 0）。于是插件二次读到的不是负数，而是 0，回滚分支永远不成立，函数返回成功；随后授权逻辑又按订单全额给作者入账。
结论是：买家最多只损失到余额下限，作者却按每一单全额收款，差额就是凭空产生的积分。从"透支"升级成了"积分增发"。
为了证明这个因果链，它设计了对照实验：把下限改成允许负数再跑一遍，回滚就稳定触发、透支消失。
量化结果（本地复现环境，买家余额 111、单价 100、下限 0）：
| 场景 |
结果 |
| 串行对照 |
成功 1 笔 / 拒绝 1 笔，无透支 |
| 并发 2 路 × 10 次 |
透支 8/10 次，积分增发 9/10 次，最大单次增发 89 |
| 对照实验（下限允许负数） |
回滚生效，透支消失 |
阶段 5｜从"能看"到"能交"：反馈文档的三轮打磨
作者后来要求"整理成小清单再反馈"。第一版出来后，我判断不适合外发——里面混了文件指纹、代码拉取方式、发送前自查项这类内部痕迹。于是：
整理正式版，直接提交的
Hy4 重构成正式报告：问题统一编号、把"未修复"改成中性的"复测结果：仍可触发"、先肯定新版防护的正确部分再指出边界、主动加一节"已确认修复的问题"说明哪些不用再提。同时给了 Markdown 和纯文本两个版本，后者去掉格式符号，方便直接粘贴到聊天或工单。
最后我要求：
最后审查一遍，有问题的话修改好
这一轮它回读了实际代码和数据库配置，改掉了 6 处。最值得说的是其中两处：
- 报告原写"插件使用的是 extcredits2"，实际配置是另一个积分字段——一处会被作者直接反驳的事实错误；
- 某条标题写"未校验访问者身份"，但代码里其实有登录校验，缺的是权限校验——措辞不严谨，已改。
它还主动把"实测已正常"降级为"代码审查结论，未做实际验证"，把"所有验证均在隔离环境完成"改成更准确的"以代码审查与本地逻辑复现为主"。宁可少说，不说满。
三、成果展示
交付物
| 类别 |
内容 |
| 漏洞清单 |
1 项高危、3 项中危、1 项低危、1 项配置风险提醒，逐条标注文件位置与影响 |
| 复现工具 |
参数化本地复现器（含串行对照组、对照实验）、只读页面检查脚本 |
| 审查报告 |
含代码溯源、机制分析、量化数据、修复建议 |
| 作者反馈 |
正式报告 Markdown + 纯文本双版本，可直接提交 |
| 环境清理 |
测试记录、积分流水、临时文件全部回滚，帖子正文 MD5 精确复原 |
给作者的修复建议（节选）
不能用"扣完再看是否为负"来判断，因为内核会钳制。应改为带条件的原子更新，把判断余额与扣减合并为一条语句，并用影响行数判断是否成功；同时把作者入账金额与实际扣款金额挂钩。
闭环
- 问题以私密方式提交给插件作者，未在公开渠道披露 PoC 细节；
- 所有测试数据已完整回滚，服务器零残留，插件源码指纹未变；
- 全部材料做了脱敏与出处核对，未包含任何凭据、域名或账号信息。
四、真实使用感受
1. 长程任务没有断线。 这个项目横跨多轮对话、多次环境变化，中间还换过一次工作目录。Hy4 能把"哪条结论已被实测推翻""哪份文件是给作者看的、哪份是自用"一直分得清，没有出现把旧结论重新端上来的情况。
2. 最打动我的不是找到漏洞，是主动推翻自己。 第一轮那份清单里最像高危的一条，是它自己后来证伪的；新版报告里"extcredits2"这种细节错误，也是终审时它自己查出来的。做安全审计，这种"敢否掉自己上一轮输出"比多报几条问题有价值得多。
3. 证据纪律。 它会主动区分"实测""代码审查结论""推测"三种强度，并在措辞上标出来。写反馈给第三方时，这一点直接决定对方是认真修还是直接驳回。
4. 产物是分层的。 同一份结论，能给出内部速查版、正式提交版、纯文本粘贴版三种形态，而且知道哪些内容不能出现在对外版本里。这已经超出"回答问题"，更接近协作交付。
5. 效率对比。 换作人工，跨内核追调用顺序、写带对照组的复现器、逐文件做指纹溯源、再整理三版文档，是几天量级且容易漏项的工作。这次是边对话边产出，且每一步都留下了可复跑的脚本。
也要说局限（这部分我照实写）：
- 高并发结论来自本地逻辑复现，忠实复刻了扣费时序与内核钳制，但没有做线上端到端验证——因为那会在真实站点产生测试数据，我主动叫停了；
- 报告里凡涉及站点具体配置的地方，最终都靠我人工核对了一遍数据库。模型会推理，但不该替人签"事实确认"这一栏；
- 某条"已修复"的判断只基于代码阅读，它明确标注了未做实际验证，没有包装成结论。
把边界写清楚，反而比一路"全部搞定"更让我放心。
五、关于合规与脱敏
这个案例涉及漏洞，所以特意说明边界，也作为投稿材料的合规声明：
- 对象为本人自有并授权的测试站点，属防守性安全审计，目的是推动作者修复；
- 全程负责任披露：先私聊作者，不公开 PoC、不提供可直接利用的攻击代码，投稿内容仅保留机制层面的技术抽象；
- 不含任何凭据、真实域名、账号、个人信息或第三方可定位信息；插件名称、版本号、作者联系方式均已隐去；
- 测试数据完成后完整回滚，未对线上数据造成留存影响；
- 内容不涉及金融理财建议、时政议题或任何活动规则禁止的类别。
六、结语
以前我对"AI 能不能干专业活"的判断标准比较朴素：看它写得像不像。这次换了个标准——看它愿不愿意在没人提醒的情况下，去否掉自己上一轮看上去挺漂亮的结论。
从一行可疑代码，到一份能被作者直接拿去改代码的报告，中间隔着证伪、复现、回滚、溯源、终审好几道关。Hy4 帮我把这些关一道道走完了，而且在几个关键节点上，它比我更早提出"这里还不能下结论"。
这大概就是我理解的"真实生产力"：不是替你把话说漂亮，是替你把事做扎实。
#WorkBuddy #Hy4
浙公网安备33048102000118号 )
Chrome 157.0.0
Windows 10