聊一聊 AI 时代的极限单兵

x 倍 AI 工程师 = 识别与拿到高价值 + 保持好状态

和一群有趣的人做成点有趣的事儿

高价值：通过软硬技能拿到对应的结果

好状态：做好自己的事情辐射团队带动身边的人

• 星光效应：用自己的能量与习惯点亮自己身边的人
• 灯塔效应：作为团队的榜样指引着成员前进的方向
• 准则: 做正确有意义的事情
  • 主人翁意识: 把自己项目推进的事情负责到底，为结果直接负责，整体把握节奏，如果有风险及时沟通对齐
  • Kaizen: 持续迭代，始终思考如果重来一次如何做得更好？
    • PDCA循环（Plan-Do-Check-Act）计划改进 → 实施 → 检查效果 → 标准化成功经验 → 再改进
    • 简化版: 分短期、中、长期分别需要做什么？以终推始，譬如: 一年计划，从 12 月往前推每个月要达成什么目标，如果翻过来从 1 月开始月月达成，全年目标必成，拆不出来就是没看清楚，没找到方向大概率会走弯路
  • 持续思考本质，如果方向是错的，越努力要填的坑越大，保持简单与高效
  • 勇于挑战: 想清楚自己想要的到底是什么？一年后、三年、五年的目标，不设边界共同成长、持续提升自身的竞争力
• 途径:
  • 对自己负责明确大致的目标与方向
  • 就目标找到北极星指标做观测
  • 持续找到需要迭代的 TOPN
  • 观测 -> 实施 -> 观测 -> 实施，收敛风险，进入迭代飞轮

二、关于 AI 的一些思考

工程迭代的变革：

• 需求与想法比写代码更重要，需求的清晰度，模型 "性格" 的感知度决定效率高低
• 当前运维系统大概有 20w 行代码，其中 80% 代码将会被废弃，但 Vibe config 下的工程代码将会迅速膨胀
• base line: 单周完成既定的 BP 工作的同事能产出 2w+ 高质量的代码或者等同于一个 AI 盯盘消抖的能力模块的产出吧

工程的阶段 单模型 Chat -> 模型+Prompt 作为特定的工具 -> 模型+Prompt+Context 作为生产力 -> 模型+Prompt+Context+Observability 作为自驱动系统

• Prompt: 比谁写得更加巧妙，充分 PUA 模型的性能，不过不同的模型使用的姿势可能不同，譬如: claude3.5 越是 PUA 它越是高效，而 claude4.0 PUA 过头了就直接摆烂，举一些具体的例子:
  • 当大模型还是 Chat 交互方式的时候出现了很多封装好了 Prompt 的小工具，譬如: 翻译助手，日志、代码分析助手等，Prompt 就像是大模型的汇编语言，而大模型就是机器。
• Context: 在有限的大模型上下文窗口内，通过结构化、优先级和语义压缩策略，动态编排关键信息以最大化任务效能
  • 有限窗口: 模型上下文长度有硬性上限（如 4K/8K/128K tokens），无法无限扩展。
  • 结构化编排: 对输入信息进行分层、删减、重组（例如：指令前置、摘要代替原文、关键数据表格化）。
  • 优先级控制: 将核心指令和任务关键信息置于开头/结尾（模型对首尾位置敏感）。
  • 语义压缩: 用简洁表达替代冗余描述（如用 {角色: 要求} 的 JSON 结构代替自然语言段落）。
  • 举几个例子:
    • 通用的 RCA: 如果在数据源维度爆炸的情况下，仅仅是分析最近几分钟的数据都会超过模型所承载的上下文大小，那不如先思考分析的对象是什么？怎么把最需要分析的内容摘选出来？ -> 那不如看异常期间变化量最剧烈的 TOPN，它最可能是异常数值，数据就被降维了。
    • Cursor/Trae/xx Code 与 Vibe config 管理
      • 为啥早期付费的 Trae 干不过免费的 Cursor? 我的理解是 Context 工程做得不够高效，保持有限的高注意力的窗口（模型 Context 支持 128k 并不代表 32k 和 128k 的效果是一样的
        • 上下文感知维度: 代码语义 + 用户行为 + 工程结构
        • 信息压缩策略: AST 解析 → 提取关键依赖/接口，上下文体积减少 40-70%，模型更易捕捉逻辑本质。
        • 动态更新机制: 时响应光标位置/文件切换
        • 意图推理能力: 关联报错、TODO、Git 变更
      • 代码风险分析扫描: 我之前有尝试过用 Qwen3 来分析代码，在面对大工程时 128/256k Context 是真有点捉襟见肘了，我做的一个尝试是把所有数据结构和函数都当成一个对象拆分开，如果这个函数依赖其他函数则记录他们的栈信息，当下依赖什么数据结构就导入什么数据结构，绝大部分场景都不会出问题，如果上下文依然会超过，就让模型先重构代码再来组织。
      • 本地知识库: Qwen3 4096 维的开源模型在中文场景更加友好（之前常见的是 1024/2048，可以简单的理解为精度高了一倍），Embeding/Reranker 一套解决方案开箱即用这些都是基建，得先灌入数据才行，如果数据是不同的格式、甚至还有很多脏数据的 HTML，以往得借助 DATA 工程去做 ETL，我选择的是数据生成模块 -> Agent -> 各类 MCP -> 格式化的数据 -> Embeding -> 入库，真是消费数据时 -> 查询数据 -> Reranker 再排序
    • Vibe coding 从被动配置到主动配置，填补上 AI IDE 项目孤岛的坑，AI IDE 的 context、譬如: 工程范式、技术选型、强业务背景是无法在多项目之间传递的

💡 传统 IDE 配置（如 .vscode/settings.json）只能控制编辑器界面，无法约束 AI 的认知框架。

典型应用场景

1. 规避技术债务扩散

   1 2 3

   # 禁止推荐已弃用 API block_patterns: - "old_deprecated_api("

2. 新人快速适配项目

   1	vibe apply-template onboarding # 加载团队知识包

3. 敏感操作拦截

   1 2 3 4 5

   risk_control: - pattern: "\.innerHTML =" action: "warn: 推荐 textContent" - pattern: "root_password" action: "block: 禁止明文密码"

• Context 的带来的效率提升是很可怕的，不是做了 10 倍的提升实际的效果就是 10 倍，等突破到了那个点就是质变，就像哪天都不用 find，就可以把所有工程项目都装进来直接推理，就像一个人可以充当 AI 的指挥官闭环所有事情，不再需要人与人之间的低效沟通对齐。
• 自我驱动: 本质上是更加进一步的管理 Context，并且可以自己建立观测和验证手段，持续迭代自身的 Context 与对应的，类人模式，用已知的知识去预测和验证未知的事情，这个模型和我们之前讨论的设置目标，观测，行动，观测，行动让指标持续收敛，再这个过程中精确管理 context。

有趣的现象

硅谷现在跳槽的看点不再是带团队的规模，而是是否能在一个足够小的团队里获取到足够多的算力资源

Agent主流四种范式：

• 反思（Reflection）：让Agent审视和修正自己生成的输出。例如，可以让Agent生成代码，然后再让同一个Agent检查和改进这段代码。也可以用两个Agent，一个写代码，另一个来debug。通过自我评估和迭代优化提升输出质量，使AI具备类似人类的“自我审查”能力。
• 工具使用（Tool Use）：LLM生成代码、调用API等进行实际操作。Agent不仅仅依赖自身预训练的知识和能力，还能根据任务需求，适时、恰当地调用外部工具，从而更高效、准确地完成复杂任务。比如调用web搜索工具获取实时信息，或通过代码执行工具进行复杂计算任务。
• 规划（Planning）：让Agent分解复杂任务并按计划执行。吴恩达团队提出“树状分解-网状执行”模型，允许在执行过程中根据环境反馈调整计划。例如，生成一张特定姿势的女孩图片，Agent需要通过多个步骤来完成这个任务，包括确定姿势、找到模型、合成图像等。
• 多Agent协作（Multi-Agent Collaboration）：多个Agent扮演不同角色合作完成任务。例如，一个Agent作为代码编写者，另一个作为代码审查者，通过合作提高代码质量。构建具备角色分工的Agent集群，通过协商机制实现集体智能，关键突破点在于设计有效的通信协议和冲突解决机制。

咱们摸得最多的有基于浏览器、虚拟机、workflow 的实现。

有个人项目，想实现把一块 2080TI 变成一个实习生，能接受 ta 一开始啥都不知道，最后能在某个领域里作为一个完整人力，为啥是 2080TI? 因为有魔改版 20G+ 的内存，刚好能跑一个 32B 量化版模型，参数不太多仅用推理能力，自建知识库与各种 MCP

三、AutoOPS 实战

阶段化演进路径

预计半年内实现

三个阶段

• Prompt 工具化整体提效
• Agent 模块化，人做判断来触发
• Context 极致化后反馈自闭环学习