~/share/2026-q2/ai-practice.md

10 min · live demo

INTERNAL SHARING

2026.04 · VOL.01

$ dev ./start-sharing --topic "ai-practice"

把 AI 塞进
每天的工作流里。

一个开发者视角的 AI 提效实践 —— 从自身痛点出发，
聊三个已经在用的场景，以及我对 AI 与生产关系的理解。

SPEAKERRico · AI Dev

FOLLOW-UP@xxx

SCOPE3 × Atomic Scenarios

chapter-01/previous-talk.md

承接

CHAPTER 01 · 承接上一位同事的方向

"单点 × 工作流" 是正确的骨架。

上一位同事已经给出了非常清晰的自顶向下路径：从整体工作生产关系出发，
在产/设/技/测各环节做单点提效，同时统一上下游信息标识与口径。

// 我完全认同这条路径：
单点提效是原子能力，工作流是组合模式。
没有原子能力的稳定，任何"全流程 AI"都会在复杂度里失控。

Layer 3 · 整合

统一工作流编排 · Workflow Orchestration

▲ 成熟后收束 ▲

Layer 2 · 协议

信息标识

输出口径

数据结构

上下游契约

▲ 统一标准 ▲

Layer 1 · 原子

产品PRD 结构化

设计组件规范

技术接口文档

测试用例生成

共识：先保证原子层的"可用、稳定、有效"，再谈协议层的统一，最终才是整合层的工作流编排。

chapter-02/my-perspective.md

补充视角

CHAPTER 02 · 我想补充的另一半视角

自顶向下之外，
还需要自下而上的视角。

顶层设计告诉我们"工作流该长什么样"；开发者视角告诉我们"**今天哪件事最烦**"。
两条路径交汇的地方，才是真正能落地的 AI 应用场景。

// APPROACH A

自顶向下 Top-Down

从完整工作流反推需要哪些 AI 能力，强调架构完整性与协作标准化。

视角：组织 / 工作流
起点：应该有什么
优势：体系化、可规划
风险：离真实痛点较远

&

// APPROACH B · MINE

自下而上 Bottom-Up

从开发者每天真实遇到的高频低价值工作出发，先解决"我自己被哪件小事卡住"。

视角：个体 / 工作现场
起点：当下最烦什么
优势：落地快、信号真实
输出：3 个已落地的提效场景 ↓

scenarios/01_api-doc-auto.md

scene 1 / 3

SCENARIO 01 · ENGINEERING

No.01 // 前后端联调场景

自动化接口文档

lark-cli + 约束 schema → 开发完成即文档完成

PAIN · 这件小事每天都烦我

接口改了 → 手动改文档 → 前端不知道字段变了 → 拉群对齐 → 联调卡住。
每周花在这条链路上的隐性成本，远超想象。

FIX · 用约束替代描述

让 AI 从代码中按固定 schema 生成文档，而不是让人"写得更勤快"。
核心思路：约束先于生成，保证输出可预测、可 diff、可复用。

+20%

JOINT DEBUG EFFICIENCY

↓ query

FIELD INQUIRY FREQ.

$ lark-cli gen:doc ● live

# 输入：已变更的后端接口
POST /api/strategy/list

# 约束 schema
@DocField(name="page", type=int)
@DocField(name="size", type=int)

# 输出：规范化文档
→ strategy-list.md
  ✓ 字段说明
  ✓ 返回结构
  ✓ 调用示例
  ✓ 变更 diff

# 关键：开发完成 = 文档完成

scenarios/02_daily-report.md

scene 2 / 3

SCENARIO 02 · TEAM SYNC

No.02 // 每日同步场景

日报结构化工具 · Peter

口语化输入 → Summary / Plan / Blocker 三段式

PAIN · 写日报比干活还累

工作记忆是碎片化的，但日报要求是结构化的。
每天花 15–20 分钟组织措辞，而 leader 扫一眼 30 秒就过了。

FIX · 把格式交给模板，把判断留给人

让 AI 做信息抽取 + 结构化填充，开发者只需"想到啥说啥"。
本质是降低写作负担，而不是替代思考。

↓ min

AVG. WRITING TIME

100%

TEMPLATE CONSISTENCY

peter.compose() ● parsing

// INPUT · 碎片化语音/文字
"今天改了登录接口，
明天要联调，
服务端还没给 token..."

extract(input) → {
  project: "auth-service",
  action: "接口改造",
  blocker: "token 待提供"
}

// OUTPUT · 结构化日报
📋 Summary of today
📅 Plan for tomorrow
🚧 Blocker / Risk

scenarios/03_hiring-toolkit.md

scene 3 / 3

SCENARIO 03 · HIRING

No.03 // 面试前后场景

招聘面试提效工具

面前 · 题单生成 | 面后 · 证据导向面评卡片

PAIN · 面试质量不该靠状态

题单临时准备 → 问题停在泛问层面；
面评写作依赖记忆 → 结论缺证据支撑，流转效率低。

FIX · 把"准备"和"沉淀"自动化

面前：简历 + JD → 45 min 高密度题单（基础盘点 / 项目验真 / 深度追问）
面后：录屏转写 + 结论倾向 → 结构化面评卡片（证据 → 判断 → 风险）

↓ min

PREP & REVIEW TIME

↑ %

EVIDENCE-BACKED RATE

interview.pipeline ● running

// BEFORE · 面前
input: resume.pdf + jd.md
output: question-sheet
  ├─ 基础盘点 (10 min)
  ├─ 项目验真 (15 min)
  ├─ 深度追问 (15 min)
  └─ 开放交流 (5 min)

// AFTER · 面后
input: transcript + verdict
output: review-card
  ├─ 证据片段
  ├─ 能力判断
  └─ 风险提示

// 核心：结论要可追溯

chapter-03/ai-and-labor.md

观点

CHAPTER 03 · 我对 AI 与生产关系的理解

AI 不淘汰人 ——
它只是改写了"熟练"的定义。

每一次生产力跃迁，都不是让"人"消失，而是让"不使用新工具的人"被使用新工具的人替代。

18TH · INDUSTRIAL

电力 → 蒸汽机

动力源更替，工厂形态被重塑，但"使用动力的人"从未消失。

19TH · TEXTILE

纺织机 → 纺织女工

机器重新定义了"熟练"的标准，懂操作新机器的人成为新一代熟练工。

21ST · INTELLIGENCE · 我们

AI → 开发者

AI 只是工具。早接触、多接触的人，会成为下一代"熟练工人"。

AI 不淘汰人，只有熟练使用更高生产力的人，才会淘汰使用落后生产力的人。 // MY TAKE

chapter-04/engineering-principles.md

收束

CHAPTER 04 · 工程方法论 · 落地前的三条戒律

边界>能力 · 约束>扩展 · 复用>炫技

// 三条排序优先级，决定一套 AI 实践能不能在团队里活下去

# 原子提效的算术题 —— 为什么先别想着"全流程 AI" 3% × 10 scenes ≈ 30% total gain // 每个场景只做 3% 的改善，10 个就是 30%
∞ complexity × 1 mega-system = out of control // 一次性接入全流程，大概率在复杂度里失控

// RULE 01

先做减法，再谈系统。

// RULE 02

先做局部闭环，再谈全局整合。

// RULE 03

先让用户拿到结果，再谈理念完整性。

一套工具如果不能在 10 分钟内被看懂、在一次使用中被感知到价值，
它就会沦为少数人的技术自娱。 // THE REAL CHALLENGE IS ADOPTION, NOT CAPABILITY

$ dev ./end-of-talk · Thanks & Q&A · 欢迎吐槽

把 AI 塞进 每天的工作流里。