丁茂华我在一次需求评审会上听到过这么一句话：“这个功能我不管技术怎么做，反正下周要上。”说话的是业务负责人，他手里攥着一份“要收集用户社交关系链并生成画像”的需求文档。当时在场的后端工程师、算法工程师、测试工程师都沉默了。没有人当场反驳，也没有人说“这不符合科技伦理”。会后走廊里我跟一位同事聊，他说了一句我一直记到现在的话：“他们在指挥，出了问题是我们技术员背锅，那伦理这块到底谁来辩护？”
后来我仔细想了想，技术执行层确实长期处在一个尴尬位置：决策权不在我们手里，但责任和舆情风险往往在我们这一环爆发。数据采集、算法上线、权限调用、灰度策略，每一条指令都有明确的业务目标，可没有一条指令会提前标注“这里可能踩到用户隐私红线”。这篇文章，就是在说这件事——当“指挥系统”和“工程执行系统”之间出现伦理真空时，技术员应该拿什么支撑自己的判断，又该怎么体面地把“我觉得不行”翻译成组织能听懂的话。
这里说的“科技伦理”，不是学院派嘴里的抽象概念，而是每天摆在代码合并请求里的具体选择：这段埋点能不能埋、这个模型的特征变量能不能用、这套营销触达逻辑要不要给用户追加一个“取消订阅”入口。现实中，这些决定往往不是由公司里的“伦理委员会”拍板的，而是被默认推给了一线技术人。你说你只是照需求文档执行，文档又不会替你上热搜。
1. 指挥者与技术员之间的信息断层，才是伦理争议的真正源头
1.1 决策链条上每个人看到的都是“局部最优”
先别急着骂管理者“不懂技术还瞎指挥”。我接触过的业务负责人和产品总监，绝大多数不是存心作恶，他们只是被考核逼着看数据看转化，眼睛里只有北极星指标。比如一个“智能推荐”功能，产品经理眼中的用户故事是“为用户推荐感兴趣的内容”，运营眼中的KPI是“人均点击率提升30%”。但从技术角度拆开，这个功能需要在客户端埋点采集你的停留时长、滑动速度、点击序列，甚至通过加速度传感器推断你是不是躺在床上看手机。敏感不敏感？非常敏感。可决策链条上，没有一个人看到完整的技术实现细节。
这就是信息断层的残酷之处：指挥者听到的永远是被提炼过的话术——“采集一点行为数据，还包含设备信息？”——他们根本不知道“设备信息”具体可以细到操作系统版本、屏幕分辨率、电池电量、WiFi名称，这几项组合起来可以相当精准地标识一台设备，跨App追踪用户。当我在评审会上把这些细节摊开时，会议室瞬间安静。不是大家不讲伦理，而是大家不知道技术底层长这样。
1.2 “技术中立”是最不负责的辩护词
“技术本身是中立的，就看人怎么用。”——这句话我早就听腻了，它在真实工程环境下完全是句正确的废话。
为什么？因为技术在落地时根本不是“一个工具”，而是一套包含了采集、存储、计算、触达的完整流程。工程师拿着“数据中立”自我安慰时，实际上已经默认参与了整个链路的设计。举一个最简单的例子：消息推送系统在代码层面就是“给用户发送通知”的工具，它有自动退订接口吗？如果没有，那用户被骚扰了只能通过卸载App来逃离。你说代码是中立的？用户卸载时留下的应用商店差评可不是中立的。
我个人的态度是：技术员在整个信息链路中最接近代码，也最接近数据流动的真相。指挥者想做灰度，技术人员能不能通过日志系统观察到灰度切量后部分用户收到了异常频繁的电话营销？指挥者说“这批用户欠费了，可以加大催收力度”，技术人员能不能从算法角度发现这个模型误伤了残障用户或老年用户？能看见并做出判断的只有执行层。如果这个层也说自己“只是写代码的”，那才是真的放弃掉科技伦理最后的防线。
1.3 谁的KPI，决定了谁的话语权重
科技伦理之所以总是被“指挥