我不是程序员，但我开始把问题做成产品I'm not a programmer, but I've started turning problems into products
一个经济学背景的非技术创作者，如何从真实生活问题出发，借助 AI 和 Vibe Coding 开始构建、验证与交付。How a builder with an economics background began using AI and Vibe Coding to build, test, and deliver ideas rooted in everyday problems.
很长一段时间，我在介绍自己时，总会先补上一句：我不是技术出身。
它像一句提前写好的解释。仿佛只有先说明这一点，别人才能理解，一个学经济学的人为什么会出现在 AI、产品原型和黑客松的现场；也仿佛我需要先承认自己“不属于这里”，才有资格继续讲后面的事。
后来我慢慢意识到，这只是我的起点，不必成为我的辩解。
我确实不是程序员，也没有一条整齐的技术成长路线。我最初接近 AI，不是因为看懂了某篇模型论文，也不是因为提前判断了什么行业趋势。更直接的原因是，我总能在生活里碰到一些让我放不下的问题。
为什么对熟悉智能手机的人来说只要几秒钟的操作，对一些长辈却像一条布满岔路的迷宫？为什么身体、情绪和照护压力的长期变化，往往要等到问题变得很明显时才被看见？为什么我们明明关心异地的父母，却常常只剩下一句“有事记得打电话”？
过去，我只能把这些问题记下来，和别人讨论，或者停在一个想法里。AI 和 Vibe Coding 改变的，不是我突然掌握了所有技术，而是我第一次有机会把一个模糊的念头推进到“可以打开、可以操作、可以被质疑”的阶段。
第一个变化：想法不再只需要被赞同
一个想法停留在脑子里时，几乎总是完整的。界面很自然，功能很有用，用户也恰好需要它。只有当它真正变成页面、流程或原型，问题才会出现。
按钮是不是太多？用户为什么要主动记录？AI 说错了怎么办？家人收到提醒后应该做什么？如果没有足够的数据，系统是不是只制造了另一种焦虑？
这些问题不会因为“初心很好”就自动消失。
我做 EasyPhone AI 时，最初看到的是一个很直观的需求：让不熟悉手机的长辈可以直接说出自己想做什么，再获得一步一步的帮助。但只要继续往下走，就会碰到更具体的边界：什么时候应该继续指导，什么时候必须停止；哪些信息不该读取；怎样确认用户真正想做的事；当 AI 不可靠时，怎样自然地转向家人帮助。
原型的意义正在这里。它不是给想法穿上一件漂亮外套，而是让想法接受现实的盘问。
第二个变化：会生成代码，不等于完成了产品
Vibe Coding 让构建的门槛明显降低。借助 AI，我可以描述需求、拆分页面、生成初版代码、追踪报错，再一点点修改交互。一个过去可能永远停在文档里的想法，现在可以较快拥有第一版。
但门槛降低之后，责任并没有消失。
AI 可以生成一个按钮，却不知道这个按钮是否应该存在；可以补全一段流程，却不会替我判断失败时谁来承担后果；可以把界面做得像一个产品，却不能证明真实的人愿意使用它。
所以我越来越把自己的工作理解为一条连续的路径：先观察问题，再明确假设；做出最小原型，找到最关键的一条使用路径；验证它是否真的降低了某种成本；最后把失败、边界和下一步都记录下来。
代码只是这条路径中的一部分。更难的部分，是决定什么值得做、做到哪里算完成，以及出现意外时怎样安全地退回来。
非技术背景不是优势，也不是原罪
我不想把“非技术背景”包装成一种天然优势。看不懂的东西需要补，工程能力需要练，做出的判断也要接受验证。仅凭对用户有同理心，并不会自动产生一个可靠的产品。
但经济学训练和过去的经历，确实让我习惯去追问另一组问题：谁在承担成本？谁获得了便利？一个看似免费的方案引入了什么新代价？当资源有限时，最值得优先解决的是什么？
这些问题不能替代技术，却会影响技术最后被用在什么地方。
我也逐渐理解，自己为什么会靠近 FDE 和 AI 应用工程这样的方向。我感兴趣的并不是在远离现场的地方追求一套完美方案，而是进入一个具体问题，听懂模糊的需求，把它拆成可以验证、可以回滚、可以复用的交付，再和真实反馈一起继续修改。
这仍然是我正在学习的能力，而不是一个已经完成的身份。
我想留下的，不只是项目列表
到现在，我做过或设想过不少轻量产品：帮助长辈使用手机，记录女性身体与情绪的变化，让异地家庭更自然地表达关心，也尝试把 Agent 的观察、计划、执行和验证做成更可靠的闭环。
它们并不都成熟，也并不都应该继续。部分只是原型，部分仍缺少真实用户验证，还有一些可能最终会被新的理解推翻。
但这些不完整的实践让我确认了一件事：我不必等到“准备好成为某种人”，才开始处理自己真正关心的问题。
我不是想证明，任何人都可以在一夜之间成为工程师。那既不真实，也不尊重专业。我更愿意证明另一件小一些的事：一个没有传统技术路径的人，也可以从真实问题出发，学习必要的工具，做出可被检验的东西，并对自己的判断负责。
这也是我建立这个网站的原因。
这里会有做出来的产品，也会有没做成的实验；会有阶段性的答案，也会有暂时没有答案的问题。我希望它不是一面陈列完成品的墙，而是一张持续展开的工作台。
保持好奇，把想法做出来。然后让现实告诉我，下一步应该往哪里走。
For a long time, I would introduce myself with a caveat: I don’t come from a technical background.
It felt like an explanation I had prepared in advance. As though I had to say it before anyone could understand why someone who studied economics was showing up around AI, product prototypes, and hackathons. As though I had to admit I didn’t belong before I could tell the rest of my story.
Over time, I came to see that as my starting point. I didn’t need to keep apologizing for it.
I’m not a programmer, and I haven’t followed a tidy path into technology. I didn’t first approach AI because I understood a model research paper or foresaw an industry trend. I kept running into problems in daily life that I couldn’t put aside.
An operation that takes an experienced smartphone user a few seconds can feel like a maze to an older person. Long-term changes in someone’s body, mood, or caregiving strain can go unnoticed until they become hard to ignore. And even when we care about parents living far away, we often fall back on, “Call me if you need anything.” Why do we keep ending up here?
In the past, I could write these questions down, discuss them, or leave them as ideas. AI and Vibe Coding didn’t give me instant mastery of technology. They gave me a first chance to make a vague idea into something someone could open, use, and question.
The first change: an idea needs more than agreement
An idea feels almost complete while it stays in my head. The interface makes sense, the features are useful, and the user needs them. I begin to notice the problems once I turn it into a page, a flow, or a prototype.
Are there too many buttons? Why would someone choose to keep records? What happens if the AI is wrong? What should a family member do after receiving an alert? Without enough data, am I creating another source of anxiety?
Good intentions don’t make those questions go away.
I began EasyPhone AI with a need that seemed straightforward: let older adults who struggle with smartphones say what they want to do and get step-by-step help. Building it meant confronting more specific boundaries. I had to consider when to keep guiding and when to stop, which information the system should not read, how to confirm the user’s intent, and how to hand over to family when the AI could not help reliably.
A prototype gives me a way to put an idea through that questioning, beyond making it look good.
The second change: generating code doesn’t finish the product
Vibe Coding has lowered the barrier to building. With AI, I can describe requirements, break down pages, generate an initial version, trace errors, and adjust the interactions. An idea that might once have stayed in a document can now have a first version in a short time.
I still carry the responsibility for what I build.
AI can generate a button without knowing whether it should exist. It can fill in a workflow without deciding who bears the consequences of failure. It can make an interface look like a product without proving that anyone wants to use it.
I have come to see my work as a continuous process: observe a problem and state the assumptions; build a small prototype and identify its essential user path; test whether it reduces a cost for someone; then record the failures, boundaries, and next steps.
Code is one part of that work. I find it harder to decide what deserves building, what counts as done, and how to back out safely when something unexpected happens.
A nontechnical background is neither an advantage nor a fault
I don’t want to present my background as an automatic advantage. I need to study what I don’t understand, practice engineering, and test my judgments. Empathy for users alone won’t produce a reliable product.
My economics training and past experiences have taught me to ask a particular set of questions. Who bears the cost? Who gains convenience? What new cost comes with a supposedly free solution? With limited resources, which problem deserves attention first?
Those questions cannot replace technical knowledge. They do influence where I put it to use.
I am also beginning to understand my interest in forward-deployed engineering (FDE) and AI application engineering. I want to work inside a specific situation, understand an unclear request, and break it into deliverables that someone can verify, roll back, and reuse. Then I want to keep revising them with feedback from use, rather than pursue a perfect solution at a distance.
I am still learning how to do that. It is not an identity I have finished earning.
I want to leave more than a project list
So far, I have built or imagined several lightweight products: helping older adults use phones, recording changes in women’s bodies and moods, helping families stay in touch across distance, and exploring more reliable cycles of observation, planning, execution, and verification for agents.
They are at different stages, and some may not deserve further work. Some are prototypes. Some still lack testing with real users. I may abandon others as my understanding changes.
These unfinished attempts have helped me see that I can start working on problems I care about before I feel ready to become a particular kind of person.
I’m not trying to prove that anyone can become an engineer overnight. That would be untrue and dismissive of the profession. I would like to demonstrate something smaller: someone without a traditional technical path can begin with a real problem, learn the tools they need, build something testable, and take responsibility for their decisions.
That is why I made this website.
It will hold products I have built and experiments that didn’t work, provisional answers and questions I cannot answer yet. I want it to feel like a workbench I keep using, with room for unfinished work alongside completed pieces.
Stay curious, make the idea, and see what happens. I can decide where to go next from there.