- 软件开发的核心问题：处理业务复杂度，并有效传递知识，达成更高的协作效率。
- 举个例子：作为一个前端，企业要求我搭建一个埋点平台，在本身埋点 sdk 之外，还涉及到监控平台的自动化部署。从技术上来说，难度并不高。如果让前端去部署，则需要：
- 向运维申请服务器权限
- 理解现有的服务器目录结构
- 构建单独的镜像
- 做完后让运维团队审核。
而直接让运维去做，这些成本完全是可以省下来的。
前端学习运维相关知识，并不是为了深挖后去干运维的活，而是在明确这个任务需要运维的协助后，尽早地去申请资源，达成更高的协作效率。
- AI 时代的软件工程师
- 不再只是代码编写者，而是AI 赋能的知识工程师
- 不再只是贡献代码，而是贡献知识
- 不再只交付需求，而是更高频度的知识迭代
- AI 落地的困境
- 技术之外，全流程参与
《为什么要成为全流程序员，而非全栈程序员？》
- 理解真实的业务问题
- 找出合适的解决方案
- 分解更小的任务列表
- 依次解决任务清单
- 全流程学习
- 履约建模法和业务方一起讨论真正要解决的问题
- 测试策略与测试工序进行架构指导
- 测试驱动开发建立良好的编码习惯
- DevOps支撑上述流程的迭代循环，建立团队工程能力
- 一个糟糕的现状
- 大家都想做基建，没人想处理真正要解决的问题
- 业务侧花大量时间给技术擦屁股，给客户解释 bug
- bug 一多，客户付费意愿降低
- 技术为了避免被裁，继续弄基建来写绩效
- 大家都在干活，但是大家都赚不到钱
- 看不起 crud 的人，连基本的 crud 都做不好
- 过多的追求 ai 的输入上下文，但是一个任务需要查询大量上下文，只能说明对代码库不熟
- 知识工程的要点：
- 如何有效提取组织知识、让知识变成 llm 能够理解的形式。通过有效沉淀大量知识，借此加速新人培养和团队打造的过程，通过更好的人与团队，构造更好的产品。
- 有哪些知识应该被有效提取：
- 业务模型图：通过领域驱动设计，进行业务建模，明确上游业务真正要什么。
- 任务分解：统一且合理测试工序，也就是我们的整体架构分层是怎样的。如果一个团队中，5 个开发有 5 种分解方案，那么这个团队的技术负责人就等于没有做任何事情。
- 文档化测试：TDD 流程中，应该时刻注重调整测试用例，将其变得可读。