★ FEATURED ARTICLE 1. 先把这条赛道的真实形状看清楚“AI挖洞”这个说法这两年被传得有点玄。我先说清楚这里的“挖洞”就是找漏洞网络安全行业的行话叫“挖洞”或者“打点”“不露脸”指的是全程线上、不用出镜、不用社交、不用坐班“一周一万”是收益预期。把这几个词拼在一起它描述的其实是这么一件事借用大模型辅助做漏洞挖掘在授权范围内提交到众测或安全响应中心拿赏金做一个安静的远程副业。我不太喜欢把这件事讲成“零门槛躺赚”因为它既不是零门槛也不是躺赚。但它确实是一条真实存在的、不需要露脸的技术变现路径而且我身边确实有人靠它拿到过一周五位数的收入。这篇文章面向三类人一是有点编程基础、想找一个能长期积累的副业方向的人二是做开发或运维、想把安全能力补上的人三是已经在做安全测试、想知道怎么把AI真正接进工作流的人不管属于哪类普通读者都能从中得到可落地的方法。我写这篇的东西主要是把“AI挖洞”拆成可执行的环节该准备什么环境、AI放在流水线的哪个位置最划算、怎么避免做无效工作、收益到底怎么分布。同时把“一周一万”这个说法拆开算给你看哪些是真实收入哪些是幸存者偏差。全程只聊授权范围内的测试这条线不能碰碰了就从技术问题变成另一个性质的问题了。1.1 “挖洞”这个词下面藏着三种完全不同的活很多人一上来就混淆了三件事导致方向一开始就跑偏。第一种是通用型漏洞挖掘目标是自己有权限测试的资产或者众测平台、安全响应中心公开授权范围内的目标。找的是常见的那几类问题注入、越权、文件读取、上传、逻辑缺陷。收益按单个漏洞算从几十到几万不等绝大多数集中在几百到几千这个区间。这是“一周一万”这个说法的现实来源也是绝大多数人真正能参与的。第二种是专项渗透测试接的是有正式委托的项目需要签协议、出报告、走交付流程。收入高但周期长通常按人天或项目结算不是“一周”能出结果的节奏而且这类活对资质和履历有要求新手基本接不到。第三种是漏洞赏金计划目标方自己挂出来的公开项目规则写得比较细赏金池有高有低。这类活的特点是竞争激烈热门目标可能几百人在看重复率极高。我建议刚起步的人直接走第一种里的“公开授权范围”部分原因是反馈快、规则相对清晰、不需要谈客户。但前提是你必须把授权边界看明白这个后面单独讲。还有一个容易忽略的分支内部资产的自检。如果你是开发者或者运维把AI-assisted的代码审计用在自己负责的项目上虽然不直接产生赏金但它能变成汇报材料里的硬通货这个隐性收益很多人没算进去。1.2 “一周一万”的账我们拆开算一遍我不喜欢用“月入过万”这种模糊说法容易误导。拆成数字更诚实。假设一个中等熟练度的选手一周投入25小时工作日晚上加周末做完一轮完整流程大致产出是这样的环节耗时占比产出资产测绘与信息收集25%得到候选目标清单人工筛掉无价值目标10%剩20%~30%值得深挖代码/流量/接口分析35%得到若干“疑似”验证与复现20%疑似里的10%~20%能打通写报告与提交10%提交若干条按经验分布一轮下来能提交的中低危漏洞大概3到8个单个赏金在几十到几百之间如果能撞上一个中高危单条可能上千。所以“一周一万”在数学上是可能的但它要求你在一周内至少命中一个高价值目标这个概率对新手来说很低对熟手来说是“偶尔”。我见过真实的收益分布长这样新手阶段前三个月多数周收益是0偶尔几十到几百。这个阶段的目标不是赚钱是把流程跑顺。进阶阶段三个月到一年月均几百到两三千偶发单周爆发。熟练阶段一年以上月均几千好的月份过万。注意任何把“周入过万”当成常态预期去宣传的说法都在偷换“最好的一周”和“平均的一周”。做这件事的正确心态是把它当成一个有复利的技术投入收益是副产物。还有一个隐性成本要算你要花时间读规则、做去重、写报告、应对审核驳回。这些时间不产生直接收益但占比不低大概占三成。很多人忽略了这块算出来的“时薪”就虚高了。1.3 AI在这条流水线里到底站哪个位置这是全文最核心的一句话AI是放大器不是发动机。它能做的事情非常具体把大量重复的、模式化的、需要快速阅读的内容处理掉。比如几千行代码里找危险函数调用、几百条请求里挑出参数可疑的、几十页接口文档里整理出攻击面清单。这些活人工做要几小时模型做几分钟而且不会累。它不能做的事情同样具体判断某个接口的业务语义、理解“这个参数改了会不会真的造成越权”这种需要业务上下文的问题、决定“这个目标值不值得继续投入”。这些必须人来。我自己的分工是这样的模型负责广度人负责深度和判断。具体说模型先把候选集从一万缩到一百人再从一百里挑出三个真正有价值的深挖。这个顺序不能反反过来就是浪费。还有一个误区要破除很多人以为用AI就是“让模型自动挖洞”指望它输出一个可以直接提交的漏洞。这条路目前走不通模型给出的“疑似漏洞”误报率极高直接提交等于浪费审核资源还容易把账号信誉做坏。正确用法是把它当成一个不知疲倦的初级分析员它给线索你给结论。2. 开工前的三道关合规、环境、模型选型动手之前有三件事必须先处理掉否则后面全是无用功。合规是第一位的这条线过了就没得谈环境决定你的效率上限模型选型决定你每天的算力成本。这三件事我建议在第一个周末全部搞定之后就不用再回头折腾。2.1 合规边界怎么确认四步走完这一步没有捷径必须逐条读因为一旦越界后面所有努力都归零而且性质会完全变化。我总结成四步第一步确认目标是否在公开授权范围内。常见形式有两种平台上的众测项目规则页会写清资产清单和禁止事项目标方自己挂出的响应中心页面会有专门的规则说明。两份都要看因为平台规则和厂商规则可能不一致以更严格的那份为准。第二步确认“禁止事项”清单。这部分比资产清单更重要。常见禁区包括不允许对生产环境做压力类测试、不允许触碰真实用户数据、不允许做社工、不允许物理接触、不允许使用自动化扫描器高频请求。有些项目明确写了“只接受手工测试”这时候你跑扫描就是违规。第三步圈定自己的测试边界。我习惯在建项目文件夹的时候第一件事就写一个scope.md把允许的域名、IP段、账号类型、时间窗口全部列进去之后所有脚本都从这个文件读目标避免手滑打错一个字符跑到范围外。第四步想清楚数据处理方式。如果你用在线模型API测试过程中抓到的数据、代码片段可能会离开你的机器。稳妥的做法是所有可能包含真实用户数据、密钥、内部标识的内容先在本地做脱敏或者干脆只用本地跑的模型。这条我踩过坑后面会讲。提示不确定某个操作是否在范围内的时候正确做法是停下来去规则页找依据或者直接放弃这个点换个方向。不要用“应该没问题”来判断。2.2 一套够用的本地环境和工具清单不需要堆工具一套精简的组合跑顺了比装二十个工具强。下面是我现在常用的按用途分用途工具说明目标发现subfinder、amass 一类子域枚举只用来扩展资产面注意请求频率存活探测httpx 一类批量探活、抓标题、指纹目录与接口发现ffuf 一类字典要自己维护公用字典命中率低抓包与改包带拦截功能的抓包客户端手工测试的主力工具漏洞模板扫描nuclei 一类只做辅助结果必须人工复核脚本环境Python 3.10请求、解析、批量处理模型运行本地推理框架跑量化后的小参数模型环境上我建议用一台独立的虚拟机或者一台闲置机器专门跑测试跟自己的日常机器隔离。原因很简单扫描过程会产生大量垃圾文件、临时脚本、抓包记录混在日常环境里早晚出事。我一般按项目建目录结构固定project/ ├── scope.md # 授权范围永远第一个写 ├── recon/ # 资产测绘结果 ├── traffic/ # 抓包记录 ├── notes/ # 人工笔记比什么都重要 └── scripts/ # 一次性脚本notes这个目录是我最看重的。AI能帮你读代码但它记不住“这个接口上周试过、返回是登录页、已经排除”这种上下文。这些必须落到笔记里否则每周都在重复劳动。2.3 模型选型本地跑还是调接口这是个实际问题很多人纠结很久。我的判断标准是看数据类型不只看模型强弱。涉及以下任一内容时我强制走本地模型真实用户数据、内部代码、账号密码、会话凭证、内部网络拓扑。这些内容离开机器就是风险跟模型强不强没有关系。纯公开信息、公开代码、脱敏后的片段、提示词调优这些可以用在线接口成本低、效果好。本地跑的现实情况要有个预期量化后的小参数模型7B到14B量级在代码阅读任务上能用但推理能力明显弱于大模型。它适合干“筛选”和“格式转换”这类活不适合干“需要多步推理”的活。如果你的机器只有普通家用配置跑7B量化版本勉强够用有张像样的显卡跑14B会舒服很多。成本上算一笔如果在线接口按量计费一轮资产分析假设消耗几十万token成本大概是几块钱。这个成本可以接受但前提是数据不敏感。我一般把在线调用限制在“公开信息整理”和“提示词迭代”这两类任务上其余全部本地。注意别一上来就追求“最强的模型”。我试过用顶级模型跑批量筛代码效果确实好但成本和延迟都上去了而且对筛代码这种任务中等模型的准确率已经足够因为后面还有人工复核这一层兜底。3. 信息收集AI介入最划算的第一站整个流程里信息收集是最适合用AI加速的环节因为它有三个特征数据量大、判断标准相对固定、错误成本低。筛错了顶多浪费几分钟不会造成实质影响。所以我把大部分自动化预算都压在这一段。3.1 资产测绘流水线怎么搭我的流水线是三段式中间不插入任何人工判断跑完再统一人工过一遍。第一段是资产扩展。从授权范围内的种子域名出发做子域枚举、证书透明度记录查询、关联资产发现。这一段工具已经很成熟重点是控制请求频率别把对方的基础设施打疼也别触发防护规则把你的IP拉黑。第二段是存活与指纹。把所有资产批量探活抓状态码、页面标题、响应头、框架指纹、证书信息。输出成结构化数据JSON或者CSV都行。第三段是分类与打标签。这一步是AI介入的地方把成千上万条资产记录丢给模型让它按“像是什么系统、可能有哪些风险面、优先级排序”输出一张清单。我一般会写一个简单的批处理脚本把结果分片喂给模型避免超出上下文长度import json, requests def chunk(items, size20): for i in range(0, len(items), size): yield items[i:isize] def classify(batch, endpointhttp://127.0.0.1:11434/api/generate): prompt f你是安全测试助手。下面是若干条目标资产信息 请逐条输出1) 系统类型推测2) 最值得关注的三个风险方向3) 优先级高/中/低。 只输出结论不要复述输入。不确定就写不确定不要编造。 数据{json.dumps(batch, ensure_asciiFalse)} r requests.post(endpoint, json{ model: your-local-model, prompt: prompt, stream: False }, timeout120) return r.json().get(response, ) assets json.load(open(recon/assets.json, encodingutf-8)) for batch in chunk(assets): print(classify(batch)) print(- * 40)这个脚本很短但有几个设计细节值得说。分片大小设成20是有原因的太大模型会漏项太小调用次数暴增。提示词里明确写“不确定就写不确定”也很关键不加这句模型会给每个目标都编出一个风险方向看起来很有条理实际全是幻觉。3.2 提示词怎么写才不产生幻觉这是我踩坑最多的地方说几条硬经验。第一限定输出格式。让模型输出表格或者固定字段的JSON比让它自由发挥可靠得多。自由发挥的结果通常是“该资产存在潜在的注入风险建议进一步测试”这种正确但没用的废话。第二要求标注置信度。我通常在提示词里加一句“对每个结论标注高/中/低置信度低置信度的结论单独列在最后。”这样我扫一眼就知道哪些可以直接跳过。第三禁止它推断不存在的字段。典型翻车是这样的资产信息里只有状态码和标题模型却开始分析“该CMS的某个插件存在已知问题”而它根本没看到版本号。加一句“只能基于输入中出现的字段判断不得引入输入中没有的信息”能挡掉大部分这类问题。第四给几个示例。一行示例胜过五句描述。我一般给两条输入输出样例模型的输出风格立刻就稳了。一个比较稳的提示词骨架长这样角色你是辅助安全测试的分析助手。 任务对输入的资产记录做分类和优先级排序。 约束 1. 只使用输入中出现的字段不引入外部知识推断版本和组件。 2. 每条结论标注置信度高/中/低。 3. 无法判断的字段输出未知不要猜测。 4. 输出为 markdown 表格列固定为资产 | 类型 | 风险方向 | 置信度 | 优先级。 输入{...}3.3 历史文件与接口的批量清洗这一步的收益很多人低估了。目标资产上经常能捞到一些不该公开的东西备份文件、调试页面、接口文档、前端打包后残留的注释和路径。这些内容数量大、格式乱人工看不完模型读起来很快。我通常的做法是先把抓到的文本做一次粗过滤去掉纯静态资源然后把剩下的按类型分桶HTML注释、JS里的路径字符串、JSON响应体、接口文档。分桶之后逐类处理。处理JS文件的时候有个小技巧先做一次正则抽取把所有像路径的字符串提出来去重再喂给模型做归类。直接整份文件扔进去模型会被大量无关代码干扰输出质量下降。# 从 js 目录里粗提路径去重后再交给模型 grep -rhoE /[a-zA-Z0-9_\-/]{3,60} recon/js/ \ | tr -d | sort -u recon/paths.txt wc -l recon/paths.txt抽出来的路径清单我会让模型做两件事一是把明显是静态资源的筛掉二是把疑似管理接口、内部接口的单独标出来。这一步做完往往能从几千条里留下几十条值得手工看的效率提升非常明显。提示从公开可访问的页面里看到的内容和“可以直接利用”是两回事。看到备份文件路径不等于可以下载看到接口路径不等于可以调用。每一步操作都要回到授权范围那条线上判断。4. 代码审计与流量研判AI真正拉开差距的地方如果说信息收集阶段AI只是省时间那这一段它是真的能提高命中率。原因很实在人读代码会疲劳读两千行之后注意力明显下降模型不会。它的弱点是理解业务所以关键是把任务设计成“不需要业务上下文也能判断”的粒度。4.1 静态审计分片策略和“只报可疑不报结论”直接让模型审一整个项目效果很差。原因有两个上下文塞不下以及它会漏掉中间的调用链。我的做法是按函数或按文件分片然后分两层跑。第一层是单文件扫描任务是找出危险模式外部输入直接进入敏感操作、缺少校验的分支、硬编码凭证、危险的配置项。提示词里明确要求“只报可疑点不下结论不判断是否可利用”。第二层是跨文件串联把第一层报出来的可疑点连同它的调用方一起打包再问一次“这个数据流从入口到危险操作是否连通”。第一层的提示词我一般这样写任务对下面的代码片段做安全审查。 只做三件事 1. 找出所有来自外部的输入点参数、header、文件、环境变量。 2. 找出所有敏感操作点数据库查询、文件读写、命令执行、反序列化、模板渲染。 3. 判断输入点与敏感点之间是否存在过滤或校验若存在指出校验位置。 不要判断是否可利用不要给出修复建议不要总结。 输出格式表格列 行号 | 类型 | 说明 | 是否有校验。这个提示词的关键在于禁止它下结论。我发现一旦允许它说“这里存在注入风险”它就会对每个字符串拼接都报一遍正确率不高但噪音极大。只让它做结构化的定位人工再判断效果好很多。第二层串联的时候我一般手工把相关文件拼成一个上下文控制在模型窗口的一半以内。太长了它会丢信息实测下来超过窗口60%之后准确率明显下降。4.2 抓包流量的二次研判手工测试的时候抓包工具里会积累几百上千条请求。很多人就盯着自己关心的那几条看其余的躺着。这里其实有价值一些参数只在特定页面出现一些接口返回了不该返回的字段。我的处理方式是把流量导出成结构化格式然后做两轮筛选。第一轮是规则筛选用脚本处理不消耗模型算力找出响应体里包含敏感字段名的、响应长度异常的、状态码是200但返回内容像报错的、请求参数数量特别多的。这些都是值得手工看的目标。import json, re SENSITIVE re.compile(r(idCard|phone|email|token|secret|balance|salary|internal), re.I) hits [] for line in open(traffic/export.jsonl, encodingutf-8): item json.loads(line) body item.get(response, {}).get(body, ) or if SENSITIVE.search(body): hits.append({ url: item.get(request, {}).get(url), matched: SENSITIVE.findall(body)[:5], len: len(body) }) for h in hits[:50]: print(h)第二轮才交给模型把筛出来的请求和响应片段打包让它判断“响应中是否包含超出当前用户权限范围的数据”。这个任务模型做得不错因为判断依据就在响应体里不需要业务上下文。注意处理真实流量数据时一定先脱敏。我的做法是脚本里直接对敏感字段做掩码只保留字段名和长度不保留值。这样既不影响判断也不会让真实数据离开机器。4.3 业务逻辑这块模型基本帮不上忙这句话我要说得直白一点涉及业务语义的漏洞模型目前基本无能为力。典型的例子是越权。判断一个接口是否存在越权需要知道这个资源属于谁、当前登录用户是谁、系统的权限模型是怎么设计的、这个操作在这个业务场景下是否合理。这四个信息里前三个在流量里看不出来第四个需要人理解业务。我的做法是把这部分完全交给人但用AI做前置准备让它把接口清单整理成表格标注每个接口的参数、方法、可能的资源标识符。整理完之后我人工过一遍专门挑那些“参数里带ID”的接口重点看。参数带ID的接口值得关注的原因很朴素资源标识符出现在请求里就意味着服务端需要根据它来判断权限而这类判断最容易出问题。这个经验不是模型给的是踩出来的。我一开始也指望模型帮我找越权试了几轮之后放弃了它给的结论十条里有九条是错的剩下一条还是我本来就能看到的。所以这一段的分工要认清模型做整理和归类人做判断和验证。指望着全靠模型产出会很有限。5. 验证、写报告与提交节奏前面的活都是“找线索”这一段才是“换成钱”。很多人前面做得很漂亮卡在最后一步验证不彻底、报告写不清、提交节奏乱。这三件事都有方法。5.1 PoC复现的最小闭环一个能提交的漏洞必须满足三个条件可复现、有影响、在范围内。缺一个都会被驳回。可复现的意思是别人拿着你的步骤能在同样的环境下得到同样的结果。这就要求你把前置条件写清楚需要什么账号、什么权限、什么浏览器状态、请求的完整内容。我见过很多报告只写“访问某URL修改参数即可”这种基本都会被要求补充材料。影响的意思是你要能说清楚“这件事造成了什么实际后果”。是读到了别人的数据、是拿到了不该有的权限、是造成了服务异常。说不清后果的通常只能按低危处理甚至不收。范围内这个前面讲过了不重复。验证的时候我有个习惯用两个不同账号交叉验证。A账号的资源和B账号的资源互换身份去访问看结果。这个动作能挡掉大量“看起来像越权其实不是”的误判因为有些系统的资源本来就是公开的。PoC脚本我一般用Python写短、直接、不依赖额外库方便审核方复现import requests BASE https://target.example # 使用测试账号的凭证绝不使用真实用户数据 H_A {Authorization: Bearer account-A-token} # 步骤1A 账号创建资源拿到资源 ID r1 requests.post(f{BASE}/api/items, headersH_A, json{title: test-item}, timeout10) item_id r1.json()[id] print(created:, item_id) # 步骤2用 B 账号访问 A 的资源观察返回 H_B {Authorization: Bearer account-B-token} r2 requests.get(f{BASE}/api/items/{item_id}, headersH_B, timeout10) print(status:, r2.status_code) print(body preview:, r2.text[:200])这段代码的重点不是技术含量是结构清晰创建、切换身份、访问、打印。审核的人一看就懂。实测下来这种写法的报告通过率比大段文字描述高不少。5.2 报告怎么写才能一次过报告是唯一直接决定收入的东西值得单独花时间。我的模板固定五段不多不少段落内容常见错误概要一句话说清是什么问题、影响什么写成一整段技术描述复现步骤编号步骤每步一个动作步骤跳跃省略前置条件请求响应完整的原始请求和响应只贴截图不贴文本影响说明具体到数据、权限、范围写“可能导致严重后果”这种空话修复建议一到两条具体可执行的大段抄通用建议第五段很多人不写其实写了有加分。修复建议不用很长说清楚“在服务端对资源归属做校验”这种程度就够了比抄一整页最佳实践有用。还有几个细节截图要带完整的地址栏或请求上下文别只截一小块时间戳要能对上测试账号要注明是自建测试账号。这些看起来是小事但审核每天看成百上千份报告细节清楚的那份处理得最快。5.3 提交节奏与去重别把时间浪费在重复上新手最容易犯的错误是找到一个点就急着提交提交完发现跟已有报告重复。重复的报告不计收益还拉低账号的处理优先级。我的做法是提交前先做三件事一是搜一下目标的历史公开报告看有没有同类问题二是看一下这个目标最近的提交活跃度太热的目标先放一放三是把自己的发现按“独特性”排个序先提交别人不太可能碰到的那些。节奏上我一般不在同一时间段集中提交大量同质报告。原因很实际审核会认为这是批量扫描的结果处理优先级会降低。相比之下一条扎实的中危报告价值往往高于五条模糊的低危。还有一个反直觉的经验别追热点目标。一个目标刚公开的时候几百人同时在看你花三天找到的点可能第一天就被人提交了。反而是那些冷门的、规则写得细的、资产面大的目标竞争小值得长期蹲。6. 踩坑实录与速查表下面这些是我自己撞过的还有一些是跟同行交流时听来的。写出来不是为了吓人是让你少走几个月的弯路。6.1 五个典型翻车场景场景一把模型的输出直接当结论提交。早期我信了模型一次它指出某个接口存在越权我扫了一眼觉得像就写了报告。结果审核回复是“该接口无需鉴权属于公开数据”。从那以后我给自己定了规矩模型给的任何结论必须先手工验证一遍验证不了的不提交。场景二在线模型泄露了测试数据。有一次我把一段包含内部字段名的响应体贴进了在线对话窗口虽然事后确认没有造成实际影响但那一刻我意识到流程有漏洞。现在的规矩是所有可能包含真实数据的片段先进脱敏脚本再过一遍正则检查确认没有敏感字段才允许离开本机。场景三自动化扫描跑太猛被防护拦了。这个坑很多人踩过。批量扫描没控制并发直接把目标的一个服务打出了大量错误日志虽然没造成故障但被判定为超出授权范围的行为。现在我的扫描脚本里固定加限速参数并发不超过5每秒请求不超过3宁可慢。场景四报告写得太技术审核看不懂。我一开始觉得写得越专业越好结果被要求补充“这个漏洞到底会造成什么影响”。后来我改成在概要第一句就写人话“攻击者可以读取其他用户的订单信息”后面再上技术细节。通过率立刻就上来了。场景五只盯着一类漏洞忽略了整体。有一段时间我专门找某一类问题结果在一个目标上耗了两周一无所获。后来换了个思路先把目标的接口面摸全再决定深挖哪个方向效率差别很大。方向上不要钻牛角尖要及时换。6.2 问题速查表现象可能原因处理方式模型输出全是“可能存在风险”提示词没限制结论改为只报位置不下结论模型漏掉明显的问题上下文太长信息被稀释缩小分片控制在窗口一半以内报告被驳回说无法复现前置条件缺失补账号状态、完整请求、环境说明提交后判定重复目标太热或未做前置检索换冷门目标提交前先检索历史扫描被拦截并发过高或特征明显降并发、加延迟、换时间段收益长期为零流程跑得顺但方向不对复盘目标选择别只盯技巧本地模型跑不动显存不足或未量化换更小参数量化版本降低批大小6.3 关于这件事能不能当主业说点实在的结论先说不建议在早期把它当唯一收入来源。原因是收益的波动性太强。它不是一个“投入时间越多收入越线性增长”的活而是一个“积累越多、命中概率越高”的活。前三个月可能一分钱没有这段时间的心态很容易崩。如果没有其他收入打底人会被迫去追那些低质量、高重复的目标反而把账号信誉做坏。比较稳的路径是有主业的情况下当副业做用半年时间把流程跑顺、把工具链打磨好、把目标池养起来。等月均收入稳定在某个你认为可以覆盖生活成本的水平再考虑调整比重。这个过程我见过快的一年慢的两年多个体差异很大。还有一个容易被忽略的点这件事的真正价值不在赏金本身。它带来的是安全思维和工程能力这两样东西在任何技术岗位上都值钱。我认识的人里靠这条路最后转去做安全工程、做代码审计、做研发流程改进的收入增长幅度都远超赏金本身。提示把它当成“练能力顺带赚点钱”的项目心态会稳很多把它当成“快速变现的捷径”大概率三个月就放弃。最后分享一个我自己在用的笨办法每周固定开一次半小时的复盘只记三件事这周做了什么、哪里卡住了、下周改一处什么。不写长就三行。坚持下来之后我发现真正让人进步的从来不是多学了几个工具而是把同一个错误不犯第二次。AI能帮我把广度铺开但把一件事做深、做对还是得靠自己盯着。
阅读完成 · 觉得有帮助？
