谷中仁的博客

西西的第一手原创歌曲

Fri, 04 Sep 2026 00:00:00 GMT

太阳出来喽！

爸爸妈妈去上班

我上幼儿园。

“我不想去幼儿园了”

Wed, 26 Aug 2026 00:00:00 GMT

西西上幼儿园一周了，之前一周每天都是开开心心地说：“幼儿园太好玩了！”；妈妈问：“你在幼儿园想爸爸妈妈吗？” 西西会说：“不想，幼儿园有老师，我想老师。”

这周每天回来妈妈依旧会问她：“幼儿园好玩么？” 西西说：“不好玩。” 妈妈说：“为什么？” 西西说：“我不喜欢 coco 老师！” 说这说这就开始号啕大哭。

人在基于AI交付的流程中是不可代替的

Fri, 21 Aug 2026 00:00:00 GMT

现状

2022 年 11 月 30 日，ChatGPT 以研究预览版的形式向公众开放。此后，AI 在代码补全、重构、测试和交付自动化方面快速发展。Prompt、Agent、Harness、Loop 和 Graph 等方法，也在不断扩大 AI 可以处理的任务范围。

软件开发的速度因此得到明显提升。Vibe Coding 等方式可以让人用很少的代码完成一个小功能，甚至完成一个简单应用。但是，在面向大量用户的软件交付中，人的作用仍然重要。

AI 可以替代大量执行工作，但暂时不能替代人来定义目标、接受风险、授予权限和承担结果。人在 AI 时代可能成为软件交付的瓶颈，但这不表示人必须亲自执行每一步操作。

软件交付流程中的 AI 参与度

软件交付流程大致包括需求挖掘与设计、编码实现、测试、部署、监控与维护。不同业务对 AI 的依赖程度不同。

需求挖掘与设计

在需求阶段，AI 可以帮助团队收集信息、分析竞品、整理会议内容和生成用户故事。

在 B2C 或 B2B 业务中，AI 可以访问公开的竞争产品，分析功能和用户流程，并生成改进建议。团队仍然需要检查数据来源、版权、隐私和服务条款。
对于没有现成产品参考的业务，AI 只能根据已有数据和团队提供的上下文进行推断。它可以提出假设，但不能把假设当成经过验证的需求。
对于临时的小需求，用户可以直接使用 Prompt 让 AI 生成实现方案。此时人的工作可以很少，但仍然需要定义验收标准。

例如，AI 分析一个竞品后，建议增加“自动续费”功能。这个建议从产品角度看很合理，但它可能忽略不同地区的自动续费规则。产品负责人必须确认用户价值、合规要求和业务成本，然后决定是否立项。

因此，AI 可以生成需求产物，但领域人员必须确认需求真实、可行并且符合约束。

编码实现

结合 Harness Engineering^[1] 和相关 Skill，AI 已经可以处理很多编码任务。一个需求经过规划后，可以进入标准化的 Loop Engineering^[2] 流程，并由 AI 辅助完成端到端交付。

流程

准备代码仓库
- 切换到主分支并拉取最新代码。
- 检查工作区状态，确认没有未处理的改动。
- 以最新主分支作为本次任务的基线。
创建特性分支
- 用不超过 30 个英文字符的短语概括本次变更。
- 使用连字符连接单词，并将短语用于特性分支名。
- 基于最新主分支创建特性分支，例如 fix-validation 或 add-user-search。
实现功能并提交
- 在特性分支上完成编码实现。
- 遵循项目规范，并优先复用仓库中的模式、工具和测试方式。
- 补充单元测试、集成测试和必要的验证逻辑。
- 完成功能后提交变更，并保持每次提交聚焦。
重构
- 使用重构工具改善代码结构。
- 只进行不改变行为的改进，例如减少重复逻辑、改善命名和拆分过长函数。
- 重构后重新运行测试，并修复由重构引入的问题。
审查
- 使用独立审查流程检查当前分支相对主分支的变更。
- 重点检查功能正确性、测试覆盖、可维护性和回归风险。
- 汇总审查结果，并返回实现流程处理问题。
修复审查问题
- 修复审查发现的问题。
- 重新运行测试、重构和审查流程，直到没有明确的高优先级问题。
完成交付
- 确认工作区干净。
- 推送特性分支并创建 Pull Request。
- 在 Pull Request 中说明变更内容、影响范围和验证结果。

这个流程中的编码、测试和审查工作可以高度自动化。但是，AI 仍然需要人提供目标、约束和验收标准。

例如，AI 可以根据 Jira 任务生成支付接口、测试和 Pull Request。它仍然可能遗漏退款规则、幂等要求、权限边界或旧客户端兼容性。代码通过测试，不代表业务行为正确。人需要确认这些规则，并决定是否接受这次变更。

测试

测试不仅检查代码是否运行，也检查系统是否满足真实业务的预期。单元测试和集成测试可以由 AI 辅助生成，但上线前仍需要在接近真实的环境中验证。

测试经常依赖 VPN、SSO、上游服务、下游服务、流水线和日志平台。这些依赖会限制 AI 的自动化范围。

例如，一个微服务系统需要通过 VPN 访问。测试人员先登录 SSO，再在流水线上部署上游服务、被测服务和下游服务。服务启动后，AI 可以发送请求、检查响应，并通过日志平台分析调用链路。如果这些平台提供 MCP 或 CLI，大部分检查都可以自动化。

但是，AI 仍然需要知道什么结果才符合业务要求。它可能看到接口返回 200，就认为测试成功，却没有发现订单没有进入清算系统。

对于前端变更，可以使用 Playwright MCP^[3] 或 chrome-devtools-mcp^[4] 自动执行浏览器操作。

例如，AI 可以确认点击“提交”后页面显示成功，但它可能没有发现用户连续点击两次后创建了两笔订单。人工需要确认关键业务流程、异常流程和数据结果。

AI 可以加速测试，但不能单独承担测试结论。测试结论必须由有业务责任的人接受。

部署

AI 可以生成和审查 IaC^[5]，也可以查看流水线状态。低风险变更可以自动部署，高风险变更必须具备明确的授权和责任记录。

例如，AI 发现数据库性能下降，并修改 Terraform^[6] 来增大数据库实例。这个修改可能改善性能，也可能超出成本预算，或者破坏现有的多可用区配置。人需要审查变更影响，并决定是否授权。

AI 也可能通过修改白名单解决访问问题，但同时开放不应公开的管理端口。生产环境的部署必须限制 AI 的权限，并保留审计记录。

安全的部署流程通常包括：

最小权限和明确的操作范围；
自动化检查和策略审查；
灰度发布和健康检查；
失败后的自动回滚；
高风险变更的人类审批；
随时可用的人工接管方式。

因此，人不必亲自点击每一个部署按钮，但高风险变更必须有可追责的人类授权。部署策略、权限边界和组织责任，才是这一阶段的主要约束。

监控与维护

监控可以分为静态监控和动态监控。

静态监控根据预先定义的条件检查系统。例如，CloudWatch^[7] 可以在最近 5 分钟内新增错误日志超过阈值时触发告警。

动态监控使用规则引擎或 AI 分析告警和系统行为。常见场景包括：

事件和告警分诊：AI 分析告警和日志，判断优先级并合并重复事件。
根因分析辅助：AI 关联日志、指标、Trace 和变更记录，提供排查建议。
告警降噪：AI 识别低价值告警，减少重复通知。
运行手册建议：AI 根据 Runbook 提供修复步骤，并执行低风险动作。
行为漂移监控：团队使用 online monitoring、agent tracing 和 golden datasets 观察 AI 系统的生产行为。
变更影响分析：AI 根据代码和配置变更推断可能受影响的服务。

例如，AI 认为某个错误告警长期没有造成明显影响，于是建议提高告警阈值。但这些错误实际代表消息持续进入死信队列。阈值调整后，系统可能数天都不会告警。

因此，AI 不能自由修改关键告警。阈值必须有上下限，变更必须可审计，并且必须支持回滚和人工接管。

评估模型

基于简化的软件交付生命周期与 AI 在各个阶段的使用程度，可以建立一个 AI 参与程度的示意模型。这个模型只描述 AI 在各阶段的参与和自治程度，不代表生产环境必须采用相同的自治策略。

阶段	`Level 1（人工执行）`	`Level 2（AI 辅助）`	`Level 3（AI 协作）`	`Level 4（AI 主导，人类审批）`	`Level 5（受控自治）`	`Level 6（完全自治）`
需求与设计	人工访谈、分析并编写需求。	AI 整理会议、搜索资料并格式化需求。	AI 起草用户故事、流程图和验收标准，人进行确认。	AI 根据批准的业务上下文生成依赖、任务和策略，人进行签发。	AI 根据遥测和用户反馈发现需求并提出方案，人决定是否立项。	AI 自主发现问题、确定需求、制定方案并推动需求进入交付流程。
编码实现	人工编写、测试并审查代码。	AI 提供代码补全、样板代码和局部测试。	AI 完成多文件修改、重构和 Pull Request 草稿，人进行审查。	AI 根据任务完成代码、测试、文档和策略检查，人批准合并。	AI 主动发现低风险技术债并发起修复，人保留合并和例外处理权。	AI 自主识别问题、修改代码、完成测试、合并变更并发布。
测试	人工设计和执行单元、集成及 E2E 测试。	AI 根据提示生成局部测试和测试数据。	AI 根据设计和验收标准生成并执行完整测试套件。	AI 连接测试环境、浏览器、接口和日志系统，自动验证技术结果，人确认关键业务结果。	AI 持续生成异常场景、执行混沌测试并处理低风险问题，人接管高影响问题。	AI 自主生成测试、构造异常场景、判断结果并修复问题。
部署	人工维护配置并执行部署。	AI 生成脚本、配置和故障排查建议。	AI 分析变更影响并建议部署策略，人执行或批准部署。	AI 在策略约束下自动完成测试环境和灰度部署，生产部署需要人工审批。	AI 在明确边界内执行渐进式发布、健康检查和自动回滚，人保留紧急接管权。	AI 自主选择部署策略、调整基础设施、扩缩容并执行回滚。
监控与维护	人工维护静态阈值和监控面板。	AI 将自然语言转换为查询，并生成告警摘要。	AI 关联告警、日志、指标和变更记录，起草 RCA。	AI 定位可能的故障提交，并执行经过授权的低风险修复，人批准高风险操作。	AI 在阈值、权限和回滚边界内进行预测性扩容和自动修复，人负责异常接管。	AI 自主发现异常、定位根因、修复系统并验证修复结果。

使用这个模型时，需要注意三点：

各阶段分别评估：同一个团队可以在编码阶段达到较高等级，但在生产部署和支付故障处理阶段仍然保持较低等级。
能力不等于权限：更高等级表示 AI 具备更强的分析、生成或执行能力，不表示 AI 自动获得生产操作权限。
自治不等于推荐策略：实际授权需要根据业务影响、数据敏感性、变更范围、回滚能力和审计要求决定。

例如，一个支付系统可以在编码阶段达到 Level 4。AI 可以根据 Jira 任务生成代码、测试和 Pull Request。但是，生产部署仍然需要人工审批，数据迁移和故障回滚仍然需要人工接管。因此，AI 能力等级较高，不代表整个交付流程已经完全自治。

这个例子说明，AI 的能力、AI 的权限和人的责任是三个不同概念。人的介入点应当由风险决定，而不是由流程步骤机械决定。

Level 6 表示 AI 在技术上具备端到端自治能力。它是评估模型的理论上限，不表示组织应当取消人类治理。对于支付、医疗、金融和安全等高风险系统，完全自治仍然需要受到法律、组织政策和系统边界的约束。

问题

在简化的软件交付生命周期中，AI 可以参与需求、编码、测试、部署和监控。但是，如果没有适当的人类介入，系统会产生以下风险：

需求错误：AI 生成的需求可能违背业务规则、合规要求或现实条件。
测试误判：AI 通过技术检查，但没有确认真实业务结果。
部署风险：AI 修改基础设施、访问策略或白名单时，可能造成服务中断或信息泄漏。
监控失效：AI 调整告警条件后，可能掩盖真实故障。
责任不清：发生线上事故后，组织仍然需要明确谁批准了变更，谁接受了风险。

这些问题不表示 AI 没有价值。它们说明 AI 的执行权限必须与风险等级匹配。

方案

问题不能完全消除，但可以通过流程和工具降低风险。核心原则是：人负责目标、边界、授权和责任，AI 负责分析、生成、执行和反馈。

需求挖掘与设计：AI 生成需求、流程和依赖关系。产品负责人和领域专家确认用户价值、业务规则、合规要求和资源成本。只有经过授权的需求，才能进入实现阶段。
编码实现：AI 可以完成代码生成、测试生成、重构和 Pull Request 准备。人需要提供验收标准，并审查安全、数据、权限和兼容性风险。
测试：将环境准备、接口调用、浏览器操作、日志查询和链路分析尽量代码化。对于关键业务结果，保留人工验收和风险确认。
部署：对低风险变更使用自动化发布。对生产基础设施、权限策略、数据迁移和高影响变更，保留人工授权、审计、灰度和回滚机制。
监控与维护：让 AI 分析告警、提供 RCA 和执行低风险修复。对告警阈值、扩容策略、数据修复和大范围回滚设置边界，并保留人工接管。
事故响应：AI 可以快速整理时间线、关联日志和提出修复建议。事故负责人必须判断业务影响，决定是否回滚、降级或暂停自动化操作。

这样做的目标不是让人阻塞所有操作，而是让人在真正需要判断的地方介入。自动化流程应当减少人工等待，而不是绕过必要的授权。

总结

AI 正在改变软件交付的分工。它可以生成需求草稿、编写代码、执行测试、分析告警，甚至完成部分部署和修复。

但是，软件交付不只有技术执行。它还涉及业务目标、合规要求、风险接受、权限授权和事故责任。AI 可以提供建议和执行动作，却不能独立决定组织愿意承担什么后果。

因此，人不会消失。人的角色会从直接执行者转变为目标定义者、边界设计者、风险审批者和责任主体。优秀的软件交付流程，不是让人参与每一步，而是让 AI 在明确边界内自动工作，并让人在高风险决策点可靠地介入。

参考

Harness Engineering: https://openai.com/index/harness-engineering/
Loop Engineering: https://addyosmani.com/blog/loop-engineering/
Playwright MCP: https://playwright.dev/docs/getting-started-mcp
chrome-devtools-mcp: https://github.com/ChromeDevTools/chrome-devtools-mcp
IaC: https://en.wikipedia.org/wiki/Infrastructure_as_code
Terraform: https://developer.hashicorp.com/terraform
CloudWatch: https://aws.amazon.com/cloudwatch/

“我的妈呢”

Wed, 29 Jul 2026 00:20:37 GMT

我从家辉买了1/4个西瓜回家，打开门，西西和她哥哥正坐在地上玩耍，她突然说：“我的妈呢！”

我说：“妈妈在楼底下了。”

西西又说：“我的妈呢！”

我有说：“妈妈快上楼了。”

然后西西就不说话了，继续和她哥哥玩耍了。

我吃完饭后，妈妈给她穿好了衣服，我就带着她骑车去永宁门了。

回来的路上在小雁塔和朱雀大街相交的十字路口，我们看到了西瓜，西西抬起手指着西瓜突然说：“我的妈呢！”

我愣了一下才反应过来，西西说的是西瓜的英语，不是在问她妈妈在哪，然后我笑着说：“Watermelon，西瓜的英语叫 Watermelon, 不是我的妈呢。”

在回家的路上，西西不停的说着 Watermelon。

后端开发中的 DTO,Model,Entity

Sun, 01 Mar 2026 10:59:37 GMT

AI 发展的太猛了，人人都是程序员，程序员成了最容易被代替的职业。一个被程序员写出来的程序来代替程序员了。

可替代性

程序运行之所以高效，是因为有良好的架构，算法等方法论的有效性集成。如果程序都有非专业人员来写，可能会面临很多问题，比如写出来的程序效率低下，安全性差，维护困难等问题。

可用不等于可维护，可持续演进。

如果没有专业程序员，世界上的信息化将会在现有的基础上停滞不前，甚至可能会倒退。因为没有专业程序员来维护和改进现有的系统，可能会导致上层系统出现漏洞和安全问题，甚至可能会导致系统崩溃。

至于 AI 写出来的高效的二进制代码，我们大可不必担心，代码不是越接近原生越好，至少，代码也能被审计和阅读。

虽然 AI 发展很快，但架构层面的知识仍是所有高效架构的基础，比如在哪里使用 DTO，Model，Entity 等等。AI 可以帮助我们写代码，但它不能替代我们对架构的理解和设计能力。

DTO,Model,Entity 的定义和区别

DTO,Model,Entity 在系统实现中有不同的左右，不能将所有的数据定义都放在一个地方，而是在不同的地方要有不同的实现，然后在不同的层之间实现转换。

DTO

DTO, Data Transfer Object，数据传输对象，是数据在多个层级之间传递时使用的对象。它通常是一个简单的对象，包含了需要传递的数据字段，没有业务逻辑和方法。DTO 的主要作用是为了减少层与层之间的耦合，提高系统的可维护性和可扩展性。

一般的 DTO 都是 POJO（Plain Old Java Object），即普通的 Java 对象，它包含数据字段和 getter/setter 方法，但不包含任何业务逻辑。

DTO 的主要作用是封装数据，并定义数据传输的格式，以便在多个层级之间传递。

一般，DTO 在 Controller 层和 Service 层之间传递数据，或者在 Listener 层和 Service 层之间传递数据。

RequestDTO 通常要实现一个 from 方法，将 RequestBody 转换成 Model 对象；ReesponseDTO 通常要实现一个 to 方法，将 Model 对象转换成 ResponseDTO 对象。

DTO 可用于接受下游系统传递来的数据，也可以向上游系统发送数据。

Model

Model, 模型，是数据在系统内部流转的基本单元，它通常包含了业务数据，并提供对数据的操作方法。

Model，通常只在 Service 层流转，与上游系统或数据库打交道的时候，需要将其转换成 Entity 对象或者发往第三方的 DTO 对象。

Entity

Entity, 实体，是数据在数据库中的存储单元，它通常包含了业务数据，并提供对数据的操作方法。Entity 通常是一个 ORM（Object-Relational Mapping）对象，它与数据库表结构一一对应，包含了数据字段和 getter/setter 方法，并且通常还包含了数据库操作的方法。

Entity，通常只在数据库打交道，由 Service 层转换成 Entity 对象进行数据库操作，或者将数据库查询出来的 Entity 对象转换成 Model 对象进行业务逻辑处理。

结论

AI 发展很快，但架构层面的知识仍是所有高效架构的基础，比如在哪里使用 DTO，Model，Entity 等等。AI 可以帮助我们写代码，但它不能替代我们对架构的理解和设计能力。

AI 时代需要什么？

Fri, 06 Feb 2026 23:09:08 GMT

都说过去的 2025 年是 AI 元年，各种大模型和工具争相涌现，一股百家争鸣的镜像；项目原因，在 2025 年年底浅浅的在正式项目中简单的使用了一下，那时候，AI 在编程领域已经是强到离谱，让人不经怀疑：一小撮程序员搞出了一个可以替代程序员的怪物，那作为程序员的我们还能做什么呢？我们应该是最最容易被代替的那一波人。而现在，我已经开始大规模使用 AI 来帮我写代码完成工作，通常 3 个点的卡，我基本就是 1 个小时整理业务背景及需求，然后交个 Agent 帮我 Plan 我的需求和实现计划，然后用几分钟生成代码，单元测试，集成测试等，最后再花个半小时做代码 review 和测试验证，整个流程下来，效率提升了至少 5 倍以上。

如下是我参与的一个调查的回答，分享给大家：

❓ This is a survey

As an engineer:

What you used AI for (be specific)

A:

[Design] Generate AGENTS.md file for different project to avoid inaccurate answers about the specific project, e.g. Project overview to know the background, Tech Stack to make sure to generating related tech stack code, Architecture to generate the correct file under correct folder, and API Endpoints to generate the correct API endpoint code, restrictions to tell AI clearly state the “Don’ts” and points to note, standards to make sure the code generated is in line with the project standards, and test cases to make sure the code generated is tested, commands to run the project and verify by Agent itself.

[Design] Generate the Git issue via the generate-git-issue SKILLS; the agent will generate the issue with given requirement and related linked source based on the Claude opus model.

[Design] Generate the change plan/tasks using plan mode, give more information if not enough

[Development] Generate the code with the plan in the agent mode use well-performanced AI model, e.g. Claude opus

[Development] Review code using different AI model after finish code generation in local.

[Testing] Review code via MCP, like review this PR： https://git.realestate.com.au/financial-experiences/lead-franchise-matching-service/pull/41

What you did without AI

A: operation on the source code, e.e. create branch, commit code, push code, create PR, review PR, merge PR, deploy code, monitor the production system, etc.

Operation of the JIRA card, it should be operated by AI and MCP… just need to try.

Something AI helped with that surprised you

A:

Generate the clean & correct git issue (diagrams, business test strategies… ) with small prompt( contains short requirement description and some git repo’s link)

Fix the bug with a more elegant way

should save auditTrail info from lead in the DB, skip if empty from DB and empty in the request parameter; but if empty in the DB and user provided it, should save it; I just use pseudo-code describe the logic, but the code generated by AI is more elegant and concise than my code, and it works well.

Something AI failed at

A: Generate the not good code when the prompt is short and leak of business background, tech stack, especially in the glean chat

One moment where you realized the workflow was better or worse than

A: [Better] Test & verify & fix automatically with unit-test and integration test every time after generating code

Rough time: did it speed them up, slow them down, or no change?

A: [speed them up] at most time, especially when generating code and test cases, and the time for review code is also reduced a lot.

AI 时代，你需要什么样的能力？

AI 时代，什么样的能力不会被替代，而是被需要？我觉得有如下三点：

定义问题

你的任何输入都会得到 AI 的反馈，但是不一定保证正确。

AI 模型总是会猜测你的任何问题，但是如果你给他足够多且准确的信息，那么，他就会将你的问题转化成一个清晰的技术问题，并且给出一个可靠的解决方案。

可以按照如下内容或步骤来定义你的 Prompt, AI 会更好地理解你的问题，并且给出更准确的答案：

明确目标与成功指标：集成某个外部服务，使其可以让他我们的用户提供服务。
限定约束条件：需要使用什么样的技术框架，满足什么架构要求，遵守什么样的安全规范…
拆分子问题：按照架构层次、功能模块或数据流，把大问题拆成更小的、可交付的子问题，形成可追踪的 Task。
设计验证回路：单元/集成测试如何运行并验证覆盖率。

管理

AI 模型已经是一个百事通了，但是它不一定能把所有的知识都正确的组合起来，来解决一个复杂的问题。对此，我们需要有能力来管理我们的经验/知识系统，以及管理多任务的 Agent 系统，来加速产品或项目的落地。

管理知识

知识管理是把企业经验、文档和长期记忆转化为可供模型利用的资源。一个好用的知识层，能显著提高模型的可靠性与可控性。

同时，人作为我们与 AI 交互的协作者，我们需要把人类的专业领域的经验系统性的编排起来，然后在提示词中将步骤一步一步的告诉 AI, 如此 AI 才能遵循正确的业务流程才完成任务，而不是凭空编造一个看似合理但不符合业务逻辑的答案。

通用的知识，AI 比我们知道的多。不要低估它，但也不要高估自己。

我们要做的是：把我们特有的、与业务相关的知识，结构化地管理起来，让 AI 能够正确地调用和组合这些知识。

知识库结构化：将经验总结为“活”文档（诸如，README.md, AGENTS.md, SKILL.md Confluence page, Git Repo…），搭配 MCP/Agent/Skills 等技术让其可以与模型交互。
版本与可追溯性：记录知识条目的变更历史与作者，输出时附带来源以便验证。

管理多 Agent

随着系统复杂度提升，常出现把不同能力的模型或 Agent 组合使用的需求。管理多 Agent 需要明确角色分工、通信协议与失败处理。

明确角色：给每个 Agent 一个清晰的职责（例如：Plan、generate code、tech debt manager & refactor、review…），避免责任重叠。
定义接口与契约：输入/输出格式、异常语义、超时与重试策略要事先规定好。
中央编排 vs 分散协作：复杂情景下建议采用“指挥者（orchestrator）”模式统一调度；简单流水线可用轻量链式调用。
可观测性：记录每个 Agent 的原始输入、模型版本、耗时与置信度，便于排查与演进。

常见模式：先用检索+RAG 获取背景知识，再让生成模型根据约束完成任务；或者把复杂任务拆成多轮子任务，由专门 Agent 逐一解决并最终汇总答案。

快速学习

在快速变化的领域，学习能力本身成为关键竞争力。更重要的是，把学习变成可复用的工程化流程。

小步实验：把学习目标拆成可验证的小实验，用最简单的模型与数据先试验想法。
模板化复用：把成功的 prompt、pipeline、测试用例做成模板库，供团队共享与快速复现。
读懂论文与工程实现：关注落地性强的工作，把论文中的方法先在小规模上复现验证。
复盘与知识沉淀：每个实验都写复盘，总结失败原因与可复用结论。

学习路径建议：从“问题定义→验证→集成→监控”的闭环入手，先学会把 AI 功能稳定地嵌进产品，再逐步研究更底层的新技术。

总结

AI 时代，需要更多的有经验的人。

AI 带来的不是单纯替代，而是把重复性的认知劳动放到工具里，把复杂性留给人来管理。经验丰富的人在这个阶段反而更值钱，因为他们能做的事情，更偏向判断、抽象、取舍与责任承担。

经验帮助你定义什么是“正确”的输入和输出，而不是被模型表面的“答案”迷惑。
经验让你有能力评估风险、成本和收益，从而决定何时引入模型、何时保守为上。
经验意味着能在模糊的需求里快速拆解出可交付的小目标，搭建迭代回路，让 AI 产出落地为产品价值。

换句话说，AI 并不是真正把“思考”全盘接手，而是把大量机械化的认知任务交给了工具。最有价值的岗位，反而是能用更少的尝试把问题框定准确、能管理复杂系统、并对最终结果负责的人。

AI 把工具能力放大，但不会自动带来判断力、责任和对上下文的深刻理解。那些能把问题定义清楚、建立稳定回路、并持续学习的人，在未来会更有竞争力。我们要做的，不是和模型比赛写代码，而是学会用模型去解决更有价值的、更需要经验与判断力的问题。

“妈妈，你看，月。”

Thu, 22 Jan 2026 23:48:47 GMT

昨天晚上本来想让西西早点睡觉，所以我们就早早就上床了，假装要睡觉了，可西西还是很兴奋，在主卧，客厅，次卧之间不停跑，不停大声说话。

妈妈骗她说：“外面有大灰狼，赶紧上来睡觉来。”

西西听到后，眼睛一瞪，然后慢吞吞地就上来了，上来之后又要进入她的睡觉流程了。首先拿起了她的巧虎书和巧虎笔，然后就开始点了。

突然看到最后一页，那一页是一首古诗，唐代王维的《山居秋暝》，里面有一句是 “明月松间照”, 西西看到“月” 后就兴奋了，叫到：“妈妈，你看，月。”

妈妈一看,果然是“月” 说道：“哇，西西真棒，都认识书上的字啦。” 然后娘两抱着亲了一下。

然后西西就更兴奋了，更睡不着了…

西西认识了很多字

Fri, 16 Jan 2026 23:19:45 GMT

每天下班吃完饭后，妈妈都会带着西西学习认字，她们会把学会的字贴在冰箱的一个门上，不认识的字留在下面，然后计划好明天要学哪些字；有时候奶奶也会教西西认识一些字。

有天下班到家，西西就拿着奶奶教她的飞机的飞给妈妈炫耀：“妈妈，你看，飞机的飞。” 说的时候可开心了。

妈妈也很惊讶，我回来，妈妈就给我也说了这事，然后西西又找到了飞机的飞给我炫耀她学到的字。

晚上西西睡觉前的流程快走完了，她开始在客厅和卧室之间乱串，突然，走到奶奶的卧室门口，她指着门上贴的字开始一个一个的读：“飞机的飞，大小的大，一二三四五六七八九十，红色，绿色，妈妈，奶奶…”

我站在她的后面说：“这么棒，都认识这么多字啦！” 不得不说，新脑子就是好使。

昨天晚上，我们准备睡觉了，西西突然要找飞机的飞字，我们在客厅找了一会找到了，然后妈妈就开始带着西西认字，并拍视频，妈妈让西西一个字一个字的拿起来，然后让西西对着手机摄像头叫出字的发音，刚开始，西西完全按照剧情在演，而且字发音都正确，说了一半后，整个场面就开始失控了; 原本认识的字现在故意说个错的发音，还故意做出鬼脸…

“我不喜欢我的爸爸了”

Tue, 06 Jan 2026 00:22:33 GMT

年底了还有好多假没有休完，媳妇也要去天津出差，于是我们决定去新疆玩七天，然后瞅中时机果断买了最便宜的机票，到点就飞了。

西西也完成了人生的第一次坐飞机；坐飞机前是兴奋的，坐飞机的时候是睡觉的，也没有那么兴奋了，连个天上，云朵都懒得看。

由于轻装简行，我就没有带剃须刀 🪒，所以七天下来我的胡子长得长长的，蹭西西地时候，西西就会说：“不要亲我！”哈哈，被嫌弃了。

三十一号，全家人都回家。一周没见妈妈，西西在高铁站就跟妈妈腻歪起来了，完全没我什么事了。

回到家，我们一起玩游戏，西西突然说：“我不喜欢我的爸爸了。”

我和媳妇相互看着对方表示很惊讶。

然后西西又说：“我喜欢我的妈妈。”

妈妈说：“为什么？”

西西说：“因为爸爸没刮胡子。”

我只能无语的笑笑。妈妈也只能跟着西西嫌弃，然后笑一笑。

“妈妈什么时候几天回来”

Mon, 15 Dec 2025 00:22:00 GMT

周日早上，一家人吃了饭，西西，奶奶和我拿着我们在凯德广场领的免费的电影票去看定影了，西西第一次看电影，走进电影院后看到既高又大的电影院格外好奇，虽然早到了几分钟，但是我们参观了电影院的各个地方和看到了很多海报，玩偶…

电影开始了，我们进去坐到了第三排，因为后面都没有好位置了。

电影看了前半段，讲了一对父子在海上遭遇了海浪，被迫漂流到一个叫幸福岛的岛上，上面有几个会说话的动物，然后发生了一些了可笑的事。后来岛上要举行幸福节，父子俩想要拿出最好的礼物 - 小孩妈妈送他的大虾披风，但被风吹走了。他们找啊找，追啊追，最终披风被撕成了好几片，但小动物们并不知道这个披风对小孩的意义。

小孩在帐篷里和父亲聊天，小孩突然说：“我要回家。”

西西一听就把头转过来，看我说：“爸爸，我要回家。”眼泪瞬间就下来了，然后就开始嚎啕大哭。

我赶紧把西西抱着出了电影院观影厅，然后就在影厅外抱着她，哄她说：“不哭了，不哭了，我们一会就回家。”

过了一会，西西终于平静了，我又说：“那我们现在进去继续看电影呢还是回家呢？”

西西果断地说：“回家。”

我又努力地和她交流了一下，西西还是坚持要回家。

然后我们在一楼吃了个开心果味的冰激凌就回家了。回家路上还一直要让抱着才行。

…

晚上，西西走完了所有的睡觉前的流程（玩游戏，学英语，刷牙，看书，蹦蹦跳跳），最后要睡觉了，西西趴在我的枕头边很不开心的说：“妈妈什么时候几天回来？”

我说：“7 天，21 号回来。”

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号就回来了。”

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号。”

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号。”

说着说着，西西眼睛里开始泛起泪花，然后就开始嚎啕大哭，哭着说：“妈妈什么时候几天回来？”

我抱起她哄了哄她说：”还有 7 天，下周日就回来了。“

西西又接着说：”妈妈什么时候几天回来？“

我说：“还有 7 天，下周日就回来了。”

西西终于平静了可还是不睡觉，即使眼睛在不停的眯着。然后我们又回到了床上。

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号就回来了。”

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号。”

西西说：“妈妈什么时候几天回来？”

我说：“7 天，21 号。”

…

凌晨四点，我突然醒来，西西和往常一样，在枕头那上面横着睡着, 得亏家里还是二十三四度的样子，不然光着屁股就得冻感冒了。

老父亲依旧按规律的给西西掂了个尿然后就又呼呼大睡了。