寒蝉 Hancic
我不觉得会用 AI 工具是人与人之间的差距
我不觉得会用 AI 工具是人与人之间的差距。说这话的人，不是在贩卖焦虑，就是在自我欺骗。 这句话不讨喜，但我还是想说。因为最近半年，你一定见过这些场景：朋友圈里有人截图发「我用 AI 一天干完了别人一周的活」，评论区清一色「求教程」「求带」；短视频里博主表情严肃地告诉你「不会用 AI 的人正在被淘汰
分类：科技
从技术到产品的切换
技术视角的完成由内部指标定义,全部能在开发环境里验证,却自洽地排除了"用的人怎么想"。当交互成本大于系统成本,该切换产品视角了:用「能用、好用、在用」重新定义完成,把技术包装起来,让业务知识成为使用产品的唯一门槛。
跑得快：把 Rust 判了缓刑
跑得快实录:profiling 实测 50 票纯计算不到 1 秒、全市场外推 30 秒——按决策表 Rust 取消、分区存储和 tj-web 推迟,三个大复杂度全部缓刑;把「什么时候优化」写成可对照的触发阈值。
跑得稳：不盯也能跑
跑得稳实录:任务表让跑批可追溯,调度写进代码不依赖宿主 cron(Docker/本地同构),备份先做、告警克制,以及「机制就绪不等于验证完成」的诚实边界。
跑得准：300% 的假收益与真的 IC
跑得准实录:样本扩到 50 只后发现回测里 +300% 的假收益——真实价撮合在除权日权益跳变,账户换后复权口径;补全数据校验,IC 验证动量 20 日在 10/20 日窗口显著为正。
能跑：当设计稿撞上真实数据
能跑阶段实录:契约先行防返工,接口文档和实际的落差,复权因子校验被真实数据推翻,验证逼出三个 bug,以及「10 万买不起一手茅台」的资金约束教训。
动笔之前,我画完了全套架构图
开工前我把设计做到了 v0.6,拆成四份文档,然后发现自己违背了刚写完的《架构不是设计出来的》:一行代码没写,却在讨论"怎么写对"。复盘哪些设计该留、哪些是阶段前移,以及如何用四阶段路线图补救。
跑得快：别在不知道瓶颈的地方优化
性能优化的铁律：只在瓶颈处动手。先profiling再动手，二八法则擒贼擒王。优化有成本——快vs可读的交易。基础设施优先，很多问题不靠改代码。案例：重写复杂代码效果甚微，调几个Spark参数却翻倍。
跑得稳：该花的复杂度要舍得花
到了「跑得稳」才真正开始谈架构——不是因为你终于可以展示设计模式，是因为你手上有了真实信息。容错、可观测、灰度、预案，该花的复杂度要舍得花；但不要为「万一」做架构，把复杂度放在产生最大价值的地方。
跑得准：业务结果才是唯一的验收标准
技术本身没有市场价值，真正带来价值的是它所服务的业务。用户会勉强接受一个蹩脚但能用的工具，但绝不会为一个顺手但没用的工具买单。信任比功能更脆弱——宁可功能少点，也不能为了堆功能而忽略交付的结果质量。
