我关注黑客松，不是为了证明自己很厉害I don't follow hackathons to prove how good I am
对一个非传统技术背景的独立构建者来说，黑客松的意义不是熬夜和包装，而是用有限时间暴露判断、做出证据。As an independent builder without a traditional technical background, I use short deadlines to test my judgment and produce evidence, without treating lost sleep or a polished pitch as the goal.
过去一段时间，我经常关注、报名或准备不同的黑客松和产品比赛。
我会研究赛道，阅读规则，比较一个想法是否适合在 24 小时、48 小时或 96 小时里完成；也会反复修改报名表里的那几个问题：你为什么想参加？你准备解决什么问题？为什么是你？
如果只看这些记录，很容易把它理解成一种对比赛的热衷。但对我来说，真正有吸引力的并不是名次，也不是在极短时间里证明自己能做多少功能。
我需要的，是一个有明确截止时间的实验场。
时间限制会让判断现形
一个想法没有截止时间时，可以一直变得更大。
它可以同时服务长辈、子女、社区和机构；既做健康记录，又做情绪陪伴，还要接入硬件、构建社区、形成商业闭环。文档里的每个功能都显得合理，因为它们还没有开始争夺同一份时间。
黑客松最有价值的限制，是逼迫人回答：如果只能留下一个场景，它是什么？如果用户只有三分钟，他能完成哪一件事？如果 AI 只能介入一个环节，放在哪里最值得？
这时，所谓产品能力不再是想出更多可能，而是主动放弃大部分可能。
我渐渐学会把目标从“做一个完整平台”改成“验证一个关键假设”。比如，与其声称要解决老年人的全部数字生活问题，不如先验证：当一个人不知道如何描述手机故障时，语音输入、意图确认和一张清楚的家人求助卡，能不能让求助成本降低一点。
这个目标看上去小了很多，却更接近一次可以被判断的实验。
Demo 不是结果，而是一份证据
短周期构建很容易制造一种错觉：只要页面能打开、流程能跑通，产品就已经成立。
实际上，Demo 只能证明某种交互在理想条件下能够发生。它不能证明用户愿意持续使用，不能证明模型在复杂输入下可靠，也不能证明这个方案比原来的做法更好。
但这并不让 Demo 失去意义。
在我看来，一份好的 Demo 是一份最初级的证据。它把原本只能争论的东西变成可以观察的东西：用户在哪里停顿，哪段解释太长，哪个按钮没有必要，风险边界是否清楚，三分钟演示之后，别人能不能复述这个产品到底解决了什么。
它还会诚实地暴露构建者的判断。一个项目把时间花在什么地方，通常比路演里说了什么更能说明它真正重视什么。
我不想把熬夜当成创造力的证明
黑客松文化里常有一种浪漫叙事：通宵、极限冲刺、最后一分钟提交，仿佛身体被消耗得越厉害，作品就越有诚意。
我不太认同这种证明方式。
限制时间的意义应该是帮助团队聚焦，而不是鼓励人用健康填补范围失控。尤其当 AI 已经能够承担大量资料整理、初版生成、重复修改和测试辅助时，更值得练习的是如何设计工作流，而不是如何把自己变成最后一道人工补丁。
不熬夜并不等于不投入。它只是要求我更早定义完成标准，更果断地砍掉功能，也承认有些问题无法在一场比赛里解决。
如果一个号称关心健康、陪伴或普通人的项目，必须依靠团队透支身体才能完成，它至少值得被重新审视。
给自己的五条构建规则
我正在给短周期项目建立一套更简单的规则。
第一，只选一个可以讲清楚的真实问题，不用宏大叙事替代具体场景。
第二，只做一条关键路径。用户从哪里来，做了什么，最后得到什么，必须能够完整走通。
第三，明确写下一件“不做的事”。不做诊断、不自动发送、不读取不必要的数据，或者暂时不做社区。边界越清楚，项目越可信。
第四，演示从一个人的处境开始，而不是从技术架构开始。模型、框架和工具都应该回答“它为什么让这一步变得更好”。
第五，提交时同时记录没有验证的部分。什么只是设想，什么只能在演示数据上运行，下一步最应该找谁测试，都应该被留下。
这些规则还在变化，但它们已经帮助我区分“看起来做了很多”和“真正完成了一次实验”。
比赛结束之后，允许项目结束
不是每个黑客松项目都应该变成创业项目。
有些想法在做出第一版之后，就完成了它的使命：它让我看清需求并没有想象中强，或者当前方案引入的成本比解决的问题更大。及时停下不是失败，而是实验给出了答案。
也有少数问题会在比赛之后继续留下。它们可能出现在不同的项目里，换过名字和界面，却一次次把我带回同一组人、同一种困境。这样的重复，才更像值得长期投入的信号。
所以我关注黑客松，不是为了积累一排“参赛项目”，也不是为了证明我可以在几天内变成某个领域的专家。
我只是需要不断练习一件事：在有限资源里作出判断，把问题变成可以检验的东西，再诚实地面对结果。
奖项会结束，演示页面也可能失效。真正留下来的，是我比上一次更清楚什么值得做，什么不该做，以及下一次应该先验证什么。
Over the past while, I have spent a lot of time following, applying for, or preparing for hackathons and product competitions.
I study the tracks, read the rules, and consider whether an idea fits into 24, 48, or 96 hours. I also keep revising the same application questions: Why do you want to take part? What problem will you solve? Why you?
Looking at those records, someone might think I love competitions. Rankings are not what draws me in, though, nor the chance to prove how many features I can build in a few days.
I need a place to experiment with a firm deadline.
A time limit makes my judgment visible
Without a deadline, I can keep making an idea bigger.
It can serve older adults, their children, communities, and institutions at once. I can add health records, emotional support, hardware, a community, and a business model. In a document, each feature looks reasonable. I have not yet forced them to compete for the same hours.
The useful constraint in a hackathon is having to decide: if I keep one scenario, which one? If a user has three minutes, what can they finish? If AI helps at one step, where would it do the most good?
At that point, I need to give up most of the possibilities I can imagine.
I am learning to replace “build a complete platform” with “test one important assumption.” Rather than claim I will solve older adults’ entire digital lives, I could test a narrower question: if someone cannot describe a phone problem, can voice input, intent confirmation, and a clear request-for-help card make it easier to ask a family member?
The ambition is smaller, but I have an experiment whose result I can assess.
A demo gives me an initial piece of evidence
In a short build, it’s tempting to treat a working page and a complete flow as proof of a viable product.
A demo can show that an interaction works under favorable conditions. It cannot prove that users will return, that a model handles complicated input reliably, or that the approach improves on what people do now.
I still find it useful.
A good demo gives me an initial piece of evidence. I can stop arguing in the abstract and observe where someone pauses, which explanation runs too long, which button they don’t need, and whether they understand the risk boundaries. After three minutes, can they tell me what problem the product addresses?
They can also see my priorities. Where I spend the build time often reveals more about my judgment than what I say in a pitch.
I don’t want lost sleep to prove my creativity
Hackathon culture has a familiar romantic story: an all-nighter, an extreme sprint, a submission in the final minute. It can make physical exhaustion seem like evidence of commitment.
I don’t find that a useful measure.
A time limit should help a team focus. I don’t want us to compensate for uncontrolled scope with our health. With AI able to help organize research, generate drafts, handle repeated edits, and assist with tests, I would rather practice designing the workflow than leave myself to patch everything at the end.
Protecting sleep still allows serious commitment. It asks me to define done earlier, cut features sooner, and accept that I cannot resolve some problems in one competition.
A project about health, companionship, or everyday needs deserves another look if finishing it requires the team to exhaust themselves.
Five rules I am trying for short builds
I am developing a small set of rules for short-cycle projects.
First, choose one real problem I can explain. A grand narrative cannot stand in for a specific situation.
Second, build one essential path. I need to take a user from their starting point, through an action, to a result without leaving gaps.
Third, write down one thing I will not do. No diagnosis, no automatic sending, no unnecessary data access, or no community feature for now. Clear boundaries make the project more credible.
Fourth, begin the demo with a person’s situation. I can explain the architecture afterward. For each model, framework, or tool, I should be able to say why it improves that step.
Fifth, record what I have not validated when I submit. I want to distinguish ideas from implementation, identify anything that only works on demo data, and name the people I should ask to test next.
I am still changing these rules, but they help me tell whether I have completed an experiment or only made myself look busy.
I can let a project end after the competition
A hackathon project doesn’t have to become a startup.
Some first versions teach me all I need for the moment. I might discover that demand is weaker than I assumed, or that my approach introduces more cost than it removes. I can stop with that answer instead of treating the decision as a failure.
A few problems stay with me after the event. I encounter them in different projects, under different names and interfaces, and return to the same people and difficulties. That recurrence feels more like a reason to commit for longer.
I don’t follow hackathons to collect a row of competition entries or claim expertise in a field after a few days.
I want to practice making decisions with limited resources, turn a problem into something testable, and face the result with honesty.
An award has its moment, and a demo page may stop working. I hope to come away knowing more than I did last time about what deserves building, what to leave out, and what I should test first on the next attempt.