当 AI 降低工作流壁垒，职能线与业务线怎样重新划分
一篇立场论文：职能线曾在高度分工时高效；当工具降低技能壁垒后，组织应围绕全链路业务能力重新设计。给出机制、组织形态谱系、判断信号、中美两种起点、人才需求与可否证的试点协议。
阅读摘要标签
#工程实践
围绕“工程实践”的写作、研究、项目与影像。
职场发展问题：晋升与面试前的完整自查清单
一份不压缩的问题库：围绕业务、技术、团队、个人判断与组织能力，逐项准备晋升材料、面试回答和阶段复盘。
AI 加速之后，职能线与业务线怎样重新划分
职能线曾帮助专业能力高效运转；当工具降低工作流壁垒后，组织更应围绕全链路业务能力重新设计，而不是固守历史分工。
收录于专栏 技术规划与架构 · 第 5 篇
共享核心与本地变化：多地区系统怎样演进
多地区系统既不能把所有差异硬塞进一个核心，也不能让每个地区重复建设。关键是识别稳定边界、保留扩展点，并明确模块所有权。
收录于专栏 技术规划与架构 · 第 4 篇
质量不是某个团队的任务：共同为交付结果负责
每个角色对自己的交付负责，也共同对线上结果负责。质量闭环的关键是监控、快速止损、精确修复与复盘。
工程规范怎样既减少返工，也不制造官僚流程
好规范不是把每一步都变成审批，而是让最容易失真、返工和出事故的关键交接点变得可见、可讨论、可复用。
收录于专栏 技术规划与架构 · 第 3 篇
管理者离代码多远才合适
管理者不必逐行审批代码，但若脱离一线细节，就无法判断风险、成本和团队真正的阻塞；关键是建立抽样理解，而不是微观控制。
代码为什么会变坏：从局部便利到系统债务
代码劣化并不主要来自某一次"写得差"，而来自局部变更不断绕过共同边界；真正要维护的是设计与协作的一致性。
收录于专栏 技术规划与架构 · 第 2 篇
当团队说不清独特价值时，工程师还能做什么
技术不能凭空制造卖点，但工程师仍能帮助团队更准确地理解用户、缩短验证周期，并把隐含的约束变成可选择的问题。
筛选人和面试官到底在看什么
从简历、基础到项目阐述：面试不是猜标准答案，而是让人看见你的事实、判断、学习方式与合作方式。
产品 sense：研发和产品怎么把"这个功能值不值得做"聊清楚
产品 sense 不是猜需求。从"研发如何理解产品"和"产品到底在做什么"两个角度，给出一份可照用的话题清单。
收录于专栏 一对一对话 · 第 6 篇
工程师为什么需要产品判断
从完成需求到参与规划，工程师如何把技术实现放进用户问题与业务结果之间。
收录于专栏 产品判断 · 第 1 篇
工程 POC：跨职能需求中的职责、边界与交付闭环
工程 POC 不是项目秘书，也不是替所有人兜底；它的职责是让目标、承诺、风险和决策在跨职能协作中保持清楚。
先用自己的产品：开发者如何建立真实反馈回路
自用不是"多刷一会儿产品"，而是一套从真实任务、有效证据到修复验证的反馈系统。
工程 POC 实战 FAQ：排期、同步、风险与交付
面对跨职能需求，工程 POC 应如何分工、同步风险、处理变更与控制自己的负荷？这是一份面向真实协作场景的公开 FAQ。
一次可复用的工程复盘，应该留下什么
工程复盘的价值不在于重述经过或追究个人，而在于把一次经历转化为能被验证、维护和复用的改进。
技术知识库为什么需要入口页
入口页不是链接堆栈，而是不断变化的项目留给团队的共同记忆：它帮助读者按任务进入、判断信息是否仍有效，并找到负责维护的人。
收录于专栏 文档与知识 · 第 2 篇
面试题与工程师的成长路径
2018 年春季求职后整理的面试与工程基础资料索引；保留它，提醒自己面试题从来不只是面试题。