AI 编程的产品技术实践与哲学

从编程范式到团队管理的全方位转变

本页面整合了 K+Talk 与 AI dd 峰会关于大模型如何改变软件开发流程、团队角色和产品设计的核心观点。 由谭少卿老师与一水老师共同分享的见解,帮助你理解 AI 编程的新思维与实践方法。

主题背景与活动介绍

K+Talk 与 AI dd 峰会

由 AID DAI 加研发数字峰会和 K+ 全球软件研发行业创新峰会联合冠名的线上 Talk Show, 聚焦大模型及 AI 工具在各行业落地的最新趋势。

本次分享嘉宾
- 谭少卿老师:AI 实战专家,跨领域融合开创者
- 一水老师:某大厂资深客户端架构师

核心理念

“AI 是方法,不是目的” - 把 AI 视为辅助工具,而非软件研发的终极目标

编程范式从三层(目标-计划-执行)演变,重新分配人类与AI的职责

测试驱动开发与 Agent 模式的结合,让 AI 自我修复与迭代

AI 编程与传统研发方式的对比

传统软件研发方式

瀑布式开发

各阶段顺序推进,需求、设计、开发、测试依次展开,缺乏弹性

敏捷式开发

小步迭代中不断验证与调整,需要大量团队沟通和协作,沟通成本高

人力与沟通瓶颈

随着团队规模扩大,沟通协调成本呈指数级增长

AI 编程新范式

大模型辅助编程

利用大模型生成代码、分析需求、进行自动测试,降低基础编码难度

角色分工变革

低级、重复性的编码工作由 AI 承担,人力更聚焦高水平设计与抽象

效率提升差异

高级工程师可通过 AI 获得近 90% 效率提升,初学者可能仅 20-30%,差距在于架构与规划能力

效率提升:90% vs 20% 的差距

架构师或高级工程师 (90%)

  • 对系统架构有全局把握
  • 能够清晰定义目标与任务拆解
  • 了解代码质量标准与测试范围
  • 案例:一位架构师用 AI 产出十万行可上线代码

初学者或学生 (20-30%)

  • 对需求理解不够全面
  • 难以准确表达需求给 AI
  • 无法有效审核 AI 生成的代码
  • 缺乏系统性思维与工程经验
  • 案例:学生常遇到 AI 无法准确理解复杂需求的问题

分层理解:三层次开发模式

AI 编程需要清晰的分层思维,区分人类与 AI 的职责边界,在三个层次上实现最佳协作。

定义目标 (Targeting)

确定要解决的问题和开发目标,这是人类的专业判断不可替代的环节。

关键点

  • 目标明确的关键性
  • 依赖人类的专业判断(为什么 AI 不能决定一切?)
  • 设定明确的成功标准与评价指标

案例示范

确定要开发一个用户管理模块,包括权限分配功能

计划制定 (Planning)

AI 可以协助收集信息、对比方案,提供思路,但需人工判断可行性。

关键点

  • AI 在信息收集、方案制定中的优势
  • 人机协同制定计划的典型步骤
  • 选择合适的技术栈与架构

案例示范

设计数据库模型、API接口、测试用例和性能指标

执行与编码 (Execution)

当需求和计划成型,可以'批量'让 AI 辅助写代码,并通过测试进行迭代。

关键点

  • 如何让 AI 高效写出符合需求的代码
  • 测试与迭代(为什么必须要测试?)
  • 自动化修复与优化流程

案例示范

让 AI 生成代码并自测,每轮测试自动修复错误,最终交付代码

三层协作示例:Web后端项目

1

目标定义

明确开发一个用户管理模块,支持权限分配,确定功能边界与交互要求。

2

计划制定

设计数据库模型、接口规范、测试用例与性能指标,选择技术栈与架构。

3

执行与编码

让 AI 根据需求文档和测试用例生成代码,通过 Agent 模式自测迭代,最终交付代码。

AI 编程对团队角色与管理模式的影响

AI 的引入重塑了团队结构与人员职责,对不同级别的开发者带来不同挑战与机遇。

Junior 开发者

AI 之前

负责基础编码,简单功能实现

AI 之后

面临被替代风险,需要补足工程思维与AI工具掌握

挑战

如何从'写代码'转向'管理代码生成'

机遇

更多时间投入到架构理解与业务学习

Senior 开发者

AI 之前

负责复杂模块与核心架构

AI 之后

对抽象与架构能力要求更高,需管理AI工具和人力协作

挑战

如何高效地'计划'与'目标定义'

机遇

关注更高层次的系统设计与业务集成

团队管理者

AI 之前

人员调配、进度监控

AI 之后

同时管理人力与AI数字员工

挑战

如何平衡创新与工程品质

机遇

小团队也能实现大规模业务

管理思维的转变

“没有标准就无法评价,没有评价就无法管理” - 管理本质仍是明确标准与评估

管理对象扩展至AI数字员工,需理解其能力边界

团队招聘与培养新侧重点

更注重工程意识与问题拆解能力,考察AI工具熟练度

促使每个成员成为AI+业务的多面手,不再局限于编码

AI 编程的具体实践与示例

了解如何有效地利用 AI 辅助编程,从提示词设计到测试驱动开发与 Agent 模式的实践。

提示词 (Prompt) 设计

高质量输入 → 高质量输出,提供清晰的上下文、目标和约束条件。

实施步骤

1

明确当前环境与背景

2

清晰描述期望的输出

3

提供相关约束与边界条件

实际案例

我正在开发一个电商网站(上下文),需要一个购物车组件(目标),使用React和TypeScript,须兼容移动端(约束)

测试驱动开发 (TDD)

先写测试用例,再编写功能代码,确保代码符合预期。

实施步骤

1

人先准备好需求与架构文档

2

让 AI 先产出测试用例

3

将测试与需求文档引入 Agent 模式

4

AI 循环编写、修复代码直至测试全部通过

5

人最后进行代码审阅或高级验证

实际案例

用 Cursor/Copilot 等工具让 AI 自己写、自己测、自己改,无需反复手动跑测试

Agent 模式

让 AI 像'代理人'一样,不断迭代执行任务、跑测试、自我修正。

实施步骤

1

明确任务目标与评价标准

2

设置适当的迭代次数与终止条件

3

监控AI自测与修复过程

4

在需要时提供人类反馈与指导

实际案例

创建一个对话系统,AI自动进行单元测试、集成测试,并优化代码性能

提示词设计的三要素法

1. 给定场景(上下文)

明确当前环境、背景信息、项目状态、使用的技术栈与框架

2. 目标(想达成什么)

清晰描述期望的输出、功能需求、性能要求或问题解决方向

3. 障碍(外界限制)

说明现有约束条件、可能遇到的困难、兼容性要求或边界条件

AI 与产品设计:从哲学到具体落地

AI 产品设计需要平衡技术能力与用户体验,避免过度依赖AI概念而忽视实际需求。

AI 是方法,不是目的

从商业与需求出发,解决真实问题,避免把'AI'当作噱头或唯一卖点。

关键考量

  • 过分强调AI技术而非用户价值
  • 技术推动而非需求驱动
  • 忽略实际业务场景

框架语义模型与大模型融合

将传统的结构化语义处理与大模型能力结合,提高精确度和可控性。

关键考量

  • 将用户输入切分为领域与槽位
  • 结合定制化需求与灵活性
  • 平衡规则与生成式AI的优势

多模态交互设计

菜单、按钮不会消失,而是与AI对话更智能地结合呈现。

关键考量

    衡量指标的跷跷板问题

    召回率 (Recall)

    在所有真实正例中,被模型正确识别出来的比例。召回越高,覆盖范围越广,但可能带来更多误判。

    精确率 (Precision)

    在所有被模型预测为正例的结果中,真正是正例的比例。精确率越高,结果可信度越高,但可能漏掉一些正例。

    F1 值

    综合召回率和精确率的调和平均值,经常用来平衡两者之间的跷跷板关系。

    常见问题与总结

    当 AI 能自动修复大部分 Bug,程序员是否变成创意导演?

    工程师仍需保持严谨思维和工程把关。AI使试错成本更低,有助于激发更多创意,但技术责任与架构能力仍是不可或缺的。

    AI 时代需要学管理吗?

    需要学会管理 AI本身:理解其能力模型,合理分配任务。传统管理核心依旧:识别问题、定义标准、评估结果。管理对象从纯人力扩展到人+AI的混合团队。

    未来界面会不会消失?

    交互仍需多种方式融合。人机对话与图形化控件结合是趋势,而非完全依赖对话式交互。具体场景决定最佳交互方式,未来是多模态融合的界面。

    如何快速通过AI + 经验 + 管理得到提升?

    不要只学AI用法,要学如何管理AI实际落地。利用AI学习各领域知识,加速个人经验积累。结合项目与业务目标进行实践,将方法内化为个人能力。

    结束寄语:拥抱变化,回归本质

    “解决问题”的核心逻辑始终如一。不断提升自身抽象思维与管理能力,保持对新工具的敏锐。

    最重要的是记住:AI 是强大的工具,但只有与人类的判断、创造力和专业知识相结合,才能发挥最大价值。

    © 2025 AI 编程的产品技术实践与哲学 - 从 K+Talk 与 AI dd 峰会整理

    本页面基于谭少卿老师与一水老师的分享内容创建