2026-07-07
I have realized that my desire to express myself—or perhaps my desire to write—is gradually being exhausted by the need to write massive numbers of prompts.
The moments when my imagination feels most alive now are when I am taking a shower, or lying in bed before falling asleep.
2026-06-25
Recently, through the process of hiring and managing a small team, I realized something harsh but important: in the early stage of a small team, the hardest problem is not “management structure.” The real question is: what can you offer in exchange for someone else’s seriousness?
I used to assume a simple path: recruit interns, train them, expect them to work seriously, and gradually expand the team. But reality has shown that this path is too expensive for an early-stage small team. Big companies can buy seriousness with brand recognition and résumé value. Mature companies can buy seriousness with salary and stability. Startups can buy seriousness with equity, growth, and a vision of the future. But if a small project does not yet have money, platform credibility, a clear career path, or a mature business, it will mostly attract people who are only willing to “give it a try.”
This is not a moral issue. It is an incentive issue. Whether someone works seriously depends on what they can get from the work. In general, there are only four currencies that can be exchanged for serious commitment: money, résumé value, growth, and ownership. If none of these are strong, then it is unreasonable to expect someone to naturally take responsibility for the project.
Therefore, an early-stage small team should not treat “cheap interns” as its core source of productivity. Interns can be low-risk, low-trust, low-dependency auxiliary resources. They can help with information collection, spreadsheet work, repetitive testing, initial screening, and highly structured tasks. But they should not be treated as core team members, nor should they be entrusted with work that requires strong judgment and responsibility. They simply do not have enough reason to be accountable for the final outcome of your project.
A better approach is to shift from “hiring people” to “buying clearly defined results.” Instead of recruiting a content operations intern, post a specific task: polish five interview articles, pay per article, and pay only after acceptance. Instead of recruiting a product assistant intern, post a specific task: design and label 20 test cases, and pay per completed item. Do not give someone a long-term identity from the beginning. First, look at one delivery. If they deliver reliably several times in a row, then upgrade them into a long-term collaborator.
This means that the early-stage organizational form should shift from an “intern team” to an “external capacity pool”: someone who can edit videos, someone who can write, someone who can design, someone who understands frontend development, and someone who can organize research materials. They do not have to be team members. They are project-based collaborators who can be called upon when needed.
In the short term, being the only core person is not necessarily a bad thing. For many early-stage projects, the healthier structure is: the founder owns the core judgment, AI and tools handle drafts and repetitive work, project-based freelancers deliver clearly defined outputs, and interns only enter the task pool rather than the core team. Only those who deliver consistently should gradually receive more trust and responsibility.
So the question should not be: “How do I find people to help me do all these things?” The better question is: “Which things should not be done at all? Which things can be automated? Which things can be purchased as results? Which things must be done by me personally?”
One of the biggest traps in early-stage entrepreneurship is building a low-quality team before the project itself has been validated. The founder does not gain productivity. Instead, they are dragged down by recruiting, training, rework, communication, and firing.
The order I now believe in is this: first, run the system by yourself; then purchase local capacity through small tasks; then identify reliable people from those task-based collaborators; and only then upgrade the reliable ones into owners.
The mistake in the past was giving people a team identity first, and then expecting responsibility. A better mechanism is to first observe effective delivery, and then grant more trust.
When you do not yet have enough bargaining chips, do not try to “build a team.” First, productize the work, outsource the tasks, and keep the core judgment in your own hands. The goal of an early-stage small team is not to find people who are willing to contribute unconditionally. Such people are extremely rare and impossible to rely on. The real goal is to build a mechanism: ordinary people can complete simple tasks, unreliable people leave quickly, reliable people naturally stay, and truly important judgment is never outsourced.
2026-06-23
Quantitative trading should not begin with “factor mining.” It should begin with understanding market phenomena.
Discretionary trading can be a very effective way to train this kind of market understanding, but it must be supported by recording, review, and rule formation. Eventually, the observations gained from discretionary trading should return to quantitative validation.
2026-06-17
I suddenly realized that learning something unknown is still very difficult, even with AI.
I assigned a model evaluation task to an employee I trusted, but the final result was not good. Out of curiosity, I looked at this employee’s conversations with AI, since most of our office workflow is based on interacting with AI. I found that this person did not know how to ask the right questions.
So perhaps this is the first step for many people: learning how to ask the key questions in an unfamiliar field, and then gradually using those questions to build a fuller picture.
Would the following learning model work?
First, provide foundational instruction. Then, give learners a list of “questions they can ask AI.” Learners can scan through these questions; if they already understand a topic, they can skip it and save time. Finally, they take a test without AI assistance.
2026-06-03
In many cases, the transition from AI Tool to AI Workforce is not easy. The latter sounds closer to automation and scalability, but it can also bring significant token costs, tool-calling costs, and error-correction costs.
If a company cannot find the right balance between cost and the model’s minimum usable capability, then hiring people to use AI tools more efficiently may still be the more cost-effective option.
In other words, the viability of AI Workforce does not depend simply on whether AI can complete a task. It depends on whether AI can complete a real, billable unit of work with sufficiently low cost, stable quality, and minimal human intervention.
2026-06-02
AIR is built around three core questions:
A: AI Activity — Where is the company using AI?
I: Impact — What impact is AI creating?
R: Responsibility — Who is responsible for AI?
In practice, AIR consists of four disclosure pillars:
1. AI use landscape and materiality assessment
2. AI governance and accountability mechanisms
3. AI risk, compliance, and impact management
4. AI performance, value, and verifiable metrics
The goal of AIR is to transform corporate AI from a vague narrative of “intelligent transformation” into clear, comparable, and verifiable disclosure information.
It can serve not only as an AI disclosure module within ESG reports, but also as a foundational framework for corporate AI governance, AI compliance, AI responsibility ratings, and AI maturity assessments.
Make AI use visible. Make AI impact measurable. Make AI responsibility traceable.
2026-06-01
My feeling is that the process of implementing AI applications, or transforming existing business operations through AI, is like planting flags across different parts of the world.
Some of the target locations are mountains, some are lowlands, and some are deep ocean trenches. In many places, there are no roads, so you have to take long detours on foot, because there is simply no time to build the roads first.
What the world needs is a super engineer who is familiar with every kind of terrain—and who can summarize the methods that work across similar terrains, so that future missions can reuse them.
2026-05-29
I first encountered the idea of FDE by accident last year. At that time, it did not yet have a clear name in my mind. It simply looked like the business model of a startup team: they would enter different industries, understand customer needs, bring those needs back to the company, build solutions, and then distill the common patterns of that industry into reusable knowledge and assets.
At first, I did not see how this was fundamentally different from an ordinary outsourcing team. It seemed to have only one extra step: summarizing what they had learned from the industry.
But reality has shown that this “extra step” is exactly what matters in the AI era. When AI reduces the cost of producing content, code, and solutions, the real value shifts to understanding what should be built, how it fits into real workflows, and how each customer project can be turned into reusable product knowledge.
In hindsight, the difference between an average idea and a great idea is often just one small detail. But that small detail can change the entire nature of the business.
2026-05-28
Today, I focused on two topics: world models and FDEs, or Forward Deployed Engineers.
Neither of them is merely a vague or fashionable concept. World models are an idea that has existed for years, but they are becoming increasingly important as AI moves beyond language generation toward perception, planning, simulation, and interaction with the physical world. They may not be the only path toward AGI, but they are one of the most important technical directions for giving AI a more grounded understanding of the world.
FDEs, meanwhile, represent a different but equally important shift. This role is already emerging across companies around the world, especially in AI-native organizations. It reflects the fact that AI products often cannot create value simply by being released as generic tools. They need to be embedded into real workflows, adapted to messy organizational contexts, and connected to concrete business outcomes.
In that sense, world models and FDEs point to the same broader transition: AI is moving from impressive demonstrations to real-world understanding and deployment. One is about how AI understands the world; the other is about how AI enters the world.
2026-05-27
Over the past two years, I have been consistently using AI chatbots for interactive learning in unfamiliar fields, and I often run into methodological problems.
My current framework is: AI gives a framework → AI explains → I ask questions → AI explains again → AI asks questions to check my understanding.
After actually learning this way, my experience is that:
The learning often remains somewhat superficial. It easily creates a sense of familiarity, but familiarity is not the same as mastery.
The knowledge is not tied to concrete tasks. I may understand the concepts, but I do not necessarily know how to use them.
AI tends to follow the direction of my questions, but I do not know what I have failed to ask.
Sometimes, in order to get a learning framework, I simply ask: “I want to learn X. Give me a learning path.” But this kind of prompt is actually very weakly constrained. The problem is that, in order to write a more strongly constrained prompt, I first need to understand the field to some extent. This creates a kind of vicious cycle.
After reflecting on the problems in each part of the framework, I now think a more reliable approach would be:
AI gives a framework → I read or do something → I produce output → AI critiques it → I revise → AI gives variant problems → I transfer and apply the knowledge.
What are the key points?
Ask: “What should I be able to produce?” Then work backward from the final output to design the learning path.
Make sure I produce enough output myself.
2026-05-26
I have realized that I rely too much on an engineering-oriented way of thinking in product design: What pain points do users have? At which step in the overall workflow do users need help?
However, recent examples have shown me that products often also need to deal with many sociological issues. Once the user base reaches a certain scale, will there be users who think “creatively” enough to step outside the intended product design and exploit its loopholes?
Or perhaps this is actually a pain point I failed to account for. It does exist, but only appears in low-probability scenarios. When designing a product, we should try to anticipate such cases as much as possible—or, once they occur, close the loopholes quickly.
This also makes it necessary to include different types of users in testing, because every user has different habits. In short, this feels a bit like solving sociological problems, rather than simply using product and engineering solutions to address practical difficulties.
2026-05-25
A reflection on “taste”:
The criteria for selection today should perhaps shift toward something more intuitive: a judgment of quality, a sense of what is good or bad, and an aesthetic understanding of things.
This is because comprehensive and detailed data analysis reports are already something LLMs can produce. I practice and rely on this heavily every day. But for a product, which part of a report truly matters—and whether that importance is enough to make the product “worth trying”—depends heavily on intuition. It depends on how many good and bad projects one has seen, on understanding why past projects succeeded or failed, and on being able to generalize whether those successes and failures are replicable or avoidable.
Aesthetic judgment gives us a way to ask: Was this success “elegant”? Was it an individual’s sudden rise through a low-probability event, or a team’s step-by-step execution? Is it a good business, or merely speculation? Is it based on long-term thinking, or just a temporary trend? Perhaps even that is not precise enough—the better question may be whether a temporary trend can be transformed into a long-term consideration.
