Lieflat Charts 技术拆解:惊艳的可视化是怎么被工程化出来的
最近我在给团队找一套能稳定产出高质量可视化的方案,试到一个开源 skill,叫 Lieflat Charts。同一份数据,不给 Agent 这套 skill,它很容易回到默认蓝、渐变色和拥挤图例。加上以后,出图就像换了一个人。
最近我在给团队找一套能稳定产出高质量可视化的方案,试到一个开源 skill,叫 Lieflat Charts。同一份数据,不给 Agent 这套 skill,它很容易回到默认蓝、渐变色和拥挤图例。加上以后,出图就像换了一个人。
有了新的业务需求,产品经理先整理需求点,大家讨论大致形式,设计师再出设计稿,最后交给开发编码,做成一个数据可视化组件,然后应用到具体业务里。
我本地一直装着 Whisper 做音频转文字(会议录音、课程音频、口语练习这些)。最近看到 faster-whisper,就拿去问了 AI 哪个更适合我。这个话题前后和两个 AI 讨论了三轮,加上自己实测又翻案一次,过程比结论本身更值得记录。
我后来又看了一轮这些公司的领导者访谈、官方博客和论文。之前的分析不能算错,但确实把它们分得太开了。
做了一个小实验:把一批公开投资文本整理成一个可以被 AI 调用的 Skill。
最开始我把 Skill 理解成一种更完整的 Prompt:把流程写清楚,把注意事项补全,再加上一些示例,效果应该就会越来越好。
最近在理解 AI、机器学习、深度学习、强化学习和 RLHF 的关系时,我一开始把它们当成几种并列的技术。后来发现这样理解不对。
最近在考虑一个 Mac 桌面客户端的自动更新问题。一开始我以为这件事比较简单:CI 打出一个 DMG,上传到对象存储,再让客户端定时检查版本接口就可以了。
最近在使用 Codex、Claude Code、Kimi Code 这些工具时,我一直有一个疑问:
刚才和产品经理、设计师讨论后续的产品规划,发现大家对「后续怎么做」的理解存在比较大的偏差。这里做个记录。