有人天天在补数据，却没人正式提过要改。先看这件事究竟值不值得做。
ABOUT / 关于 Edison
我想把项目里那些常被省略的过程留下来。
很多项目对外只留下一张结果图。问题最早怎么发现、哪些人需要配合、规则是谁定下来的，通常没人写。我想把这些过程留下来。
我为什么同时写技术和业务
我从企业级后端开发做起，后来被调到客户现场。到了那里才发现，客户往往只能说清目标，业务催着要结果，研发却要先拿到明确规则。我的工作也就不再只是按需求写代码。
到了现场，我会先看现在怎么做、哪里最费人、怎样才算有用，再把要确认的规则、负责人和先做哪一步写清楚。代码只是其中一部分。
这也是我理解的 FDE 工作：到现场把问题和规则问清，再把方案跟到有人实际使用。
光伏创业让我重新理解经营
2022 年做光伏创业时，我负责政府沟通、业务合作和供应链协调。那是重资产行业，资金、政策、合作方和现场条件会同时改变一项决策。
那段经历让我重新选了方向：回到我更熟悉的制造业场景，用网站、流程和数字化这些轻资产方式参与企业经营，把技术、业务沟通和项目协调放在一起用。
现在长期关注四类问题
先找总出错、总返工的环节，再决定用模型、自动化还是普通系统。
保留一线熟悉的入口，让同一批数据能被生产、管理和财务继续使用。
客户消息进来后，产品资料、物流和报价能不能及时跟上。
这里的案例怎么写
我尽量把事实、个人判断和阶段性结果分开。能确认的是现场规模、做过的动作和当前状态；没有前后测量，就不写“效率提升百分之多少”；有询盘，也不把它写成订单。
这样写少了一些漂亮结论，却更方便以后复盘，也方便读者判断能不能用在自己的场景里。