Posts

It’s been a while since I’ve written. With a moment to spare today, I want to share my experiences from the past two years of AI development and entrepreneurship. Now, in the second half of 2025, having led several AI projects including my own startup, Hika, I can make a bold claim: building AI products has become deceptively easy, but building an AI business is harder than ever. Prompt is All You Need This is an insight I shared in an article a year ago, and it holds truer than ever today. Prompt Engineering, RAG, MCP, Agents—all these fancy terms are just different ways to feed a large model a prompt with the right context. ...

全职创业已过了很长时间, 终于在 2024 年, 我们造出了值得骄傲的产品 — hika, 一个月不到已经过万用户, 收获无数细腻的好评, 详情可看: 我 All In AI 创业一年后, 成绩如何? hika 是什么? HIKA 是一款免费的知识获取引擎，为你探索世界提供全新的方式与思路，你提出问题，HIKA 会实时搜索网络，深度思考并给出答案 HIKA 有什么： 实时搜索：一个有着全网实时信息+自带知识库的答案引擎，并提供关键参考来源 图文并茂：不仅有文字，HIKA 还提供多种图表分析，并直观展现重点概念间的关系 快速解读全局知识点，一图胜千言 深入研究：可对段落进行深入解读，并提供对其包含的关键点追问 更贴合你的搜索习惯，哪里不会点哪里 ai 搜索 AI 驱动的 Hika 创业以来, 除了值得信赖, 非常靠谱的团队外(这个以后有机会再详细描述), 2024 年 最让我震撼的就是 AI. Hika 采用了 AI 与人工协作的方式开发, 减轻了大部分枯燥的代码劳动, 但数据结构, 架构, debug, 压测等等还是要我们上; 运营适配各个国家不同语言的帖子都是 AI 写的, 很多细节是我跟 AI 商讨确认对齐的 AI 让 hika 整个团队的效率提升了不止一倍, 用一个比喻就是, AI 就是你自身的杠杆, 你水平越高, 这个杠杆越能提升你的效率 当然 Hika 也完成了自举, 我们平常使用 Hika 来提升开发 Hika 的效率. 这种深度融合 AI 的开发模式不仅大大提高了我们的工作效率,也让 HIKA 成为了一个真正由 AI 驱动的产品。 ...

Hika 主页 https://hika.fyi https://www.hika.fyi Hika AI是一款AI加持的「知识搜索工具」，它主要的目的是帮助你在搜索问题时通过Hika的「不同视角的思路」，为你快速延伸问题相关的知识领域，或者深挖问题中某个关键点，获得更加全面的结果 我们为什么要做Hika 我和山尽都是AI产品的重度用户，并且长期关注知识信息类的产品，我们自己在使用AI搜索这个领域的产品时发现，虽然产品众多，但大部分都很雷同，且在使用时倍感无力，究其原因： 底层模型并没有聪明到能够懂我心 给出的答案中有很多链接，图片，但这些并没有帮助我更好的理解问题 每当我对回答的某段内容感兴趣时，却无法深入 我们发现上述问题实则是整个产品界对于AI与人交互关系的底层理解所致，而它正成为一整个该类产品的共识，因此我们想尝试提出不同的解法 Hika与其他AI搜索不一样的地方 现有的AI搜索产品基本都雷同于perplexity，文本回答+链接+相关问题+图片，它看起来像是公众号，它的探索性更针对形式而非问题本身，Hika对此的思考大体以下几点： 我们保留了文本部分作为回答的主体，同时定向加入了一些专业性知识来源，以满足基础的问答有效性 我们将回答按段落进行分割，因为你很可能对一个回答中若干个点感兴趣，而他们通常都分布在不同的段落中。Hika可以对这些段落进行进一步的交互性探索，给出联想追问或者更加深度的回答 我们提供图表化的讲解，相比文本陈述，图表本身即是另一种角度的解读，Hika的图表即可以延伸那些关联的知识点，同时也可以让你即刻拥有”全局视角“ 可以看出，我们希望能给你提供若干对于单一问题的多维思考"线索"，而不是一步到位的"懒人回答"。 这是因为我们不认为AI能在短时间内完全取代聪明的你。在思考问题时，人倾向于网状结构的信息组织方式，并将有用的信息提取加工，随后得到结论。每个人都有自己专属的加工方式与标准，它无法被量化，这也是为什么现在的AI搜索不能给所有人一个满意回答的关键原因。 因此我们不贪图一步到位的回答，而是让Hika专注于对信息的深挖，它可以大幅提升网状式获取信息的效率，换句话说，利用Hika，你的思考可以比以前更聪明，更有效率

最熟悉的陌生人：5 分钟快速理解 HTTP2 from : https://mp.weixin.qq.com/s/fb02vTE884Txx6npW2mfcQ 有些图裂了，看原文比较方便~ 最熟悉的陌生人系列，将带你快速理解熟悉的名词如：HTTP2、HTTP3、IPV6、BBR 等。 通读 90 年代上下的论文，你会发现，在已经基本建成的计算机科学大厦中，后辈码农只要做一些零星的修补工作就行了。 在计算机科学晴朗天空的远处，还有几朵令人不安的小小乌云。 ——皓尼・郝里斯（ HioHio ） 而其中一朵小小乌云，就是前辈的协议制定实现得太牢靠了，就算有着诸多不足，还是用的好好的，让后辈没什么动力去创新替换。。 HTTP 的不足 在阅读此章时，读者可以给自己一个思考时间，锻炼设计与思考能力—— 目前在用的 HTTP 协议，你认为有哪些不足呢？ 你可以重新设计一个替代它并且尽可能兼容的协议，你会怎么做呢？ 可尝试自己写下设计，定会受益甚多。 TCP 连接数过多 HTTP1.0只允许一条 tcp 链接上处理一个 request，尽管后来的 HTTP1.1(现在常用的版本）允许pipelining， 管道，通过这个管道，浏览器的多个请求可以同时发到服务器，但是服务器的响应只能够一个接着一个的返回 (但各大浏览器有些不支持 / 默认关闭，因此这功能可以说是鸡肋)。 HTTP 头部过多重复 Host、Accept-Encoding、Connection、origin、content-type等等一堆头部，都在不同的请求中重复出现。 除了浪费大量流量，还会导致 TCP 的初始拥塞窗口(initcwnd)快速满了，当多个请求准备在同一个 tcp 连接上发送时，会导致大量延迟——当initcwnd >= ssthresh （ slow start threshold ） 时，tcp 就会进入 “拥塞避免算法”，把发送的速度调慢，避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。 当然初始拥塞窗口(initcwnd)也不能调太大来避免。 If the initcwnd values is large, then there will be fewer RTTs required to download the same file. But we cannot set initcwnd to a huge value as the network environment and the routers also has the limitation of having limited buffers. If exceedingly large values are set, it may lead to router buffer overflows, packet loss, packet re-transmissions. So, we need to set an optimal value for the initcwnd which is directly proportional to the network bandwidth. ...

双向链接 最近因为Roam Research，双向链接在笔记圈子里火了起来，Notion也在准备做了，那么双向链接是什么呢？ 我用我的我关于管道的一则笔记给大家讲明白： 管道的实现 Linux里，管道实现的原理是：Shell进程先调用pipe创建一对管道描述符，然后fork出两个子进程，一个子进程关闭读端，调用dup2把写端赋给标准输出，另一个子进程关闭写端，调用dup2把读端赋给标准输入，两个子进程分别调用exec执行程序，而Shell进程把管道的两端都关闭，调用wait等待两个子进程终止。 如上，管道的实现就是我可以从其他地方点击看这个笔记内容的单向链接，只能从名字过来。 但对于我上面笔记里标红的关键词，笔记系统会提炼出关键词，并且给这些关键词自动生成/引用到有这个名字的笔记里。 那么，我以后想看dup2这个函数的详情，就可以看到关于dup2的解释，以及有什么笔记用过它。 词不达意，稍后再截图说清楚。 选择什么好呢？ 我比较喜欢稳定的折腾，不太喜欢breaking change，所以我一般选择依赖很重的工具时，会尽量选择breaking change不多的——比如vim，稳定+自定义强+简单，在不是必须IDE时我开发都用Vim+tmux+bash+git，选笔记时，我认为这会是长年使用的工具，所以我会偏向使用这种。 下面列列： Notion：太重了，我入门感觉就是啥模板都有，而且比较强调协作，面向大众，没发现有双向链接（后来得知在实现中） Roam Research：带火双向链接的创始者，收费贵，创始人言论有问题，言下之意是，收费贵就是筛选掉你们这些不愿意付钱没信仰的人 Obisdian：想跟Roam Research抢市场的后来者，不完善，界面不好看，没给我想要的感觉 以上都没给我印象强烈的点。 直到我继续看Roam Research的替代品，在一大堆替代品中，看到了熟悉的名字：TiddlyWiki。 再遇TiddlyWiki 我是Erlang作者Joe Armstrong的粉丝，三言两语讲不清楚（讲清楚就得下篇了），所以我很早就知道了TiddlyWikil了，因为他后来就用了这个当博客用（点击原文可查看他的博客）。 他用TiddlyWikil是因为对Jelly、Hugo这些博客使用markdown时，因为格式不统一上传时才有问题，不太满意；另外是他希望他写的东西，之后不会因为markdown格式问题（100年后没有markdown解释器了）而不可读： The blog is a program. You can interact with the blog. The blog contains most of the articles I’ve written in the last few years. The blog is made from a single HTML file which should run off-line in any browser. The blog contains a complete IDE powerful enough to recreate itself. The blog is a Quine. I hope the blog will be readable in 100+ years time. 当时对我来说，这些点有点意思，但对我完全不重要。。 ...